请置顶：斑竹视点，每日一文

降龙十八掌

At A Government Agency...

A clerk spent a great deal of time surfing the Internet while on the job. Because there was no policy specifying what constituted excessive personal use, management could not discipline this employee. Then management discovered that the clerk had downloaded a great deal of pornography. Using this as a reason, management fired him. The clerk chose to appeal the termination with the Civil Service Board, claiming that he couldn't be fired because he had never been told that he couldn't download pornography. After a Civil Service hearing, the Board ordered him to be reinstated with back pay.

At A Law Firm...

The manager of data processing took a job with a competing law firm. Because his former employer had nobody who could do the job that he did, they kept him on as a contractor. On a part-time basis, he would perform systems management tasks. In order to do these tasks he needed full privileges on the former employer's network. One day the former employer learned that the manager's new employer was opposing them in a high-visibility lawsuit. Could the former data processing manager gain access to the shared legal strategy files for this case on the network? The answer was yes, but nobody knew whether the manager had exploited these capabilities because no data access logs were being kept. This situation could have been avoided if the former employer had policies about conflicts of interest, system access privileges, and keeping logs.

At An Oil Company...

An oil company computer technician compiled a list of jokes about sex. Proud of his list, he broadcast this list on the Internet, appending his electronic mail address to the end, just in case the recipients happened to have heard any new ones. Management was able to have the posting deleted from several discussion groups, but was not able to control copies that had been made. Around the same time the same technician had printed a copy of his list, and when distracted by something else, had left it in the hopper of a departmental printer. Women in the department objected that they had been subjected to sex jokes via email that they didn't want to hear. They pointed to the Internet postings and the printer output as examples. The pending sexual harassment lawsuit was settled for an undisclosed sum. A policy about permissible use of the Internet, as well as a policy about representations made using the company name on the Internet were noticeably lacking.

At A Local Newspaper...

A local newspaper had no policy requiring the termination of user-ID and password privileges after an employee left. A senior reporter left the newspaper, and shortly thereafter, the newspaper had trouble because the competition consistently picked-up on their exclusive stories (scoops). An investigation of the logs revealed that the former employee had been consistently accessing their computer to get ideas for stories at his new employer.

At A Midwest Manufacturing Company...

A virus hoax sent by email through the Internet indicated that if people receive a message with the heading "Join the Crew" they should not read it. The hoax went on to state that this email would erase a hard drive if ever it should be displayed. Thinking that they were doing others a favor, 10% of the staff at a large manufacturing company broadcast the hoax to all the people they knew. Because no policy defined how they should handle these warnings, they flooded the company's internal networks with email and caused a great deal of unnecessary technical staff time to be wasted.

At a West Coast Manufacturing Company...

Because it had no policy requiring employee private data to be encrypted when held in storage, a large manufacturing company found itself facing a public relations problem. A thief made off with a computer disk containing detailed personal details and bank account information on more than 20,000 current and former employees. The press speculated that this could be used to facilitate identity theft, including application for credit cards in the names of other people. The event precipitated a massive notification process including recommendations on changes to bank account numbers.

At a Major Online Service Company...

A Navy enlisted man registered with an Internet online service company and filled out a profile form which indicated that he was gay. An employee at the service company, after an inquiry from the Navy, shared this profile information with the Navy's "top brass." Based on this information, the enlisted man was given a dishonorable discharge. The enlisted man sued the Navy for violating its own "don't ask, don't tell" policy, and won an honorable discharge with retirement benefits as a result. The online service company publicly stated that its employee had violated "the Privacy & Security Policy," but this policy had been violated on multiple occasions before including top management's publicly stated intention to sell customer home telephone numbers to telephone marketers. At least the service firm now admits that it has a policy.

降龙十八掌

Inherent security risks of outsourcing -- what the CIO should know

降龙十八掌

Companies large and small are outsourcing computing applications and partnering to create business and technology related alliances at an astounding rate. In the U.S. and global marketplace, competition is now so fierce that those who were previously competitors are partnering in order that they may share risk, preserve capital, and gain market share from other competitors. It seems as though some companies soon will have outsourced so much of their business they will be in danger of becoming a business in name or brand only. While there can be many business benefits to outsourcing business functions and partnering with vendors and others in your business, the downside is always that it brings much added risk to your supporting systems, networks, and business critical applications. The more your network is extended and the more nodes or hosts are added-then all the more intrusion vectors (new and vulnerable risk points) become available for possible exploit and resultant harm to your company. As you connect your networks with various outsourcers, partners, vendors, alliances, and even consortiums you may, and probably will, connect with whom they do. The above connection scenario changes the established trust model from explicit and understood trust to one of transitive implicit trust. This is the "I may trust you but I do not necessarily trust who you trust" scenario. What can make the issue all the more complicated is that the company you outsource critical functions to may outsource some of its critical functions as well, and, you may not realize the potential impact to you until after long-term contracts are signed. Then it may be too late to amend contracts in order to protect your company from potential loss and liability. More connections to your network will bring more intrusion vectors or risks. These risk points must be tightly controlled and monitored at all times. Some companies may have hundreds of network connections, using a variety of communication methods, e.g. Internet, frame relay, leased line, microwave, wireless, satellite, fiber, ad nauseum. With so much variety in your connection types how will you know if a breach (successful or unsuccessful) in your network has occurred? How can you know what is happening in your partner's networks, or in the networks of those whom he is connected to? It may likely be through your friendly partner connections that you become open to intrusion, not from a more direct outside intrusion. Watch those trusted host relationships carefully. Are you ready to respond to a breach of your network?

Usually, agreements are made and contracts are signed before a project team becomes involved in implementing a connection for a partner or an outsourcing contract. Use your in-house information security professional. They can offer you valuable expertise and experience before an outsourcer is chosen and contracts are signed. You will benefit from their lessons learned. If you do not have in-house professionals, hire outside professionals quickly. Retain them long-term if you need. It may also be time to review all of your current connections for risks to your business that can be easily mitigated with inexpensive controls and network re-design.

Security planning and risk assessments An adequate and formalized security planning process should be instituted to fully describe any new (or existing) projects, the controls, and residual risks to the sponsoring business line and the company as a whole. In doing so, risks are identified, and proper protective controls are implemented. The controls can be validated and a process instituted to monitor for continued compliance. In the end the residual risk should be low enough so that it is palatable to those who own or benefit from the project. A business-acceptable "Systems Security Planning Process" (based on general, platform, and technology specific standards) may include the following items. (There may be sub-sections for each section.)

Overview:
A project overview should be included that provides an executive summary of the project. The wording should be non-technical so that the application proponent(s) (see below) can easily understand the project and its components. Other applications/references: A section should be included that mentions other applications within the company that this application may interface with and any other relevant documentation.

Test schedule and target production date: Test and production target dates should be firmly established and documented. Test dates are important as network connectivity is usually first established at testing time. Since connectivity itself can be the largest risk factor you must pay close attention to connection dates. Responsible proponent(s) and auditor(s): Each application usually has an owner, sponsor, or proponent. In this case; we refer to them as the proponent. In some cases there may be several proponents. The planning process is to ensure that the proponent(s) are made aware of their risks. If your companies' auditors are involved, their names should go here as well.

Data classification:
It should be clear to the proponents when the data to be used in a project is Confidential or Company Secret rather than just Internal Use Only. If so, extra care (e.g., encryption) may be required. Architectural, network, and data flow diagrams: Data flow and network diagrams help to clearly spell out where your company data is going and what physical network devices and computing platforms are to be used. Computing platform and environment descriptions: Each computing platform may have different security requirements.

Application access paths and access matrices: It is important to specify exactly how a user will gain access to systems and what platform security controls will control that access. This is the place to spell it out. An access matrix can provide a visual layout of who has access to what resources in an application or project.

General and platform specific security standards and controls: Ideally, each computing platform used in a project will have proper standards documents associated with their use (i.e. UNIX, MS-NT, Sun, etc.) This section should state which standards are used. Standards exceptions/issues, risks/exposures and mitigating controls: After all is said and done a project may still have some, and in some cases many, residual risks and exceptions to standards. These risks and exceptions should be clearly spelled out to the project proponent(s) for their acceptance.

Contracts
Your vendors, partners and outsourcers should be held to your high control standards when they connect to your networks and have custody of your data assets. Contracts should ensure this and hold them liable for any negligence. Contracts should stipulate what controls-related reporting the outsourcer provides. Such reports will help you understand how well your data is being handled. It should be required that you be notified within a reasonable period of time of exceptions or incidents that involve your data. Contracts need to have some planned obsolescence, as they may need to be revised over time as the technology itself changes. In short, perhaps it's best to ask for every control to be addressed in the contract upfront whenever possible. Ensure when drafting the contract that you maintain complete control of the relationship, and that you maintain control of your most critical systems. In other words ensure that your contracts protect you and not the outsourcer. Ensure that your contracts provide you with the right to properly oversee and audit the outsourcer at your convenience. Consult with your in-house counsel and find experienced outside counsel if you must. Caution should be taken here. Your business is at risk.

Networking controls (firewalls and encryption)
After you and your vendor/partner have agreed on a secure and mutually acceptable contract and network connection design, you're ready to connect and begin business. Well designed, configured, and closely monitored firewalls, supported by a concerned, attentive, and expert staff are absolutely key. All connections should consist of TCP/IP- based protocols only, if at all possible, and all must go through a central firewall method (we mention method, as there may be many actual machines). Routing all of your connections though a central point can provide you the ability to know exactly who is coming in and going out, and when. Obviously, one door is easier to guard than many, and since firewall rules become vastly complex, you want them in one place to assist in preventing configuration errors. This is one of those rare situations where having all your eggs in one basket is a good idea. It is just that you must be very diligent in watching that one basket. Of course, you will need a redundant basket hardware failures that inevitably occur at the worst possible moment.

降龙十八掌

Though there is some added cost, terminating connections can be segregated at the firewall method to further minimize your risks. Internet connections should terminate on separate subnets than frame relay, SNA, or point-to-point connections. Sensitive connections should be isolated from each other, as should encrypted links. Vendor owned, controlled, and supported connections, servers, and routers must be isolated with strictly defined, mutually agreed upon, and monitored routing and access controls. If a vendor supported server is successfully attacked, make sure it does not affect you because you let the vendor talk you into an ill-advised server-to-many-servers trust relationships for the sake of convenience.

Due to the number of network connections and their increasing complexity, the firewalls themselves can become difficult to manage and oversee. Firewall rules can become increasingly complex, installation of security software patches can lag behind, and monitoring can take more time than is available. Due to these issues some companies are even outsourcing their firewalls, monitoring, and maintenance to outside firms. Whether this is right for your company or not is up to you to decide.

Awareness and education
Again, today, your vendors and partners may not be aware of your issues, or of network security issues in general. Your first line of defense is to have experienced information security professionals provide counsel to you and represent your best interests. If you don't have these professionals, find them quickly. Ask them to come in and train your staff. You will find it money well spent and it can help to avoid costly future issues-and it will help in vendor negotiations by agreeing on contract terms upfront. Rather than repeating the same message over and over again to those with whom you connect, consider working with your security professionals to develop a briefing on what your issues are and what you expect. This briefing can be general in scope so that you can feel free to e-mail it to them over the Internet. You may want a separate more detailed briefing complete with network diagrams, computer names, and network addresses that you can discuss once non-disclosure agreements are in effect.

The briefing should include a checklist of items so that they can be prepared to answer your basic questions-the information you need in order to ascertain how you'll need to treat them: friendly or hostile. A friendly connection partner will have provided you with favorable third-party audit reports (standard auditing reports such as a SAS-70 and network penetration tests) and will not require the use of insecure networking protocols (e.g. UDP, ICMP, SNMP, etc.). And what are hostile connections? They may be those whom are extremely reluctant to provide you with any information, or those that may plainly have less than desirable controls and connections themselves, and know it.

Issues to evaluate with outsourcers, vendors, etc.

Physical security: Card-key access, cameras, guards, etc.
Personnel security: Procedures for screening employees, such as FBI fingerprint checks, etc.
Procedural security: General and platform specific security standards
Customer referrals: Contact current and past customers. Listen carefully to what others may tell you before contracts are signed.
Change management procedures: Look for detailed procedures with separation between test and production.
Determine their networking protocols: IP networks are inherently more risky than SNA networks. If the network is IP determine what risky protocols are being used (i.e. UDP, ICMP, etc.).
Determine the vendor's connectivity: Are they connected to the Internet, or to your competitors?
Contractual liability specifications: Determine and agree on who will be liable for what and under what circumstances.
Year 2000 compliance: Determine Year 2000 certification status and ensure the contract covers the issue adequately.
Intrusion detection and overall network and firewall security methods, controls and monitoring: Ensure that vendor controls access to their network in an adequate manner.
Third-party audits (SAS-70 and penetration tests): Obtain and review any third-party security reports your vendor can provide.
Adequate insurance: Computer crime, fraud, property, general liability, etc.: To protect your company ensure your vendor is adequately covered.
Business resumption planning: Be certain your vendor is capable of providing your business with service in the event of a disaster at their primary processing site.
Regular audits
Audits should occur on an adequate periodic basis to validate agreed upon controls at your site and the other party's site. Consult your EDP audit department for guidance. Ally yourself with them, you will find them more than willing to do so with you.

Conclusions
As we all become interconnected we also become interdependent upon each other for our security needs. We must act together as a neighborhood watch patrol. Due to changing technology and the new electronic commerce marketplace we each must raise the bar on security. We must all protect our networks adequately against today's modern threats and tomorrow's unknown-and perhaps even more insidious-threats. We must demand that our vendors, partners, and outsourcing providers educate themselves in regard to our security concerns. Today, as most all applications are designed to be networked, they must be secure by design and default, not only after your own thorough analysis and fine-tuning conducted after purchase. Security is quality, and applications, networks and service should deliver built-in quality. Our common goal should be common high standards and controls so that we may protect shareholder's assets, maintain customer's privacy, and maintain quality and available systems in support of profit making motives.

降龙十八掌

今天我们继续围绕Seruciry Policy进行讨论

降龙十八掌

The characteristics of a good security policy are:
1. It must be implementable through system administration
procedures, publishing of acceptable use guidelines, or other
appropriate methods.
2. It must be enforceable with security tools, where appropriate,
and with sanctions, where actual prevention is not technically
feasible.
3. It must clearly define the areas of responsibility for the
users, administrators, and management.
The components of a good security policy include:
1. Computer Technology Purchasing Guidelines which specify
required, or preferred, security features. These should
supplement existing purchasing policies and guidelines.
2. A Privacy Policy which defines reasonable expectations of
privacy regarding such issues as monitoring of electronic mail,
logging of keystrokes, and access to users' files.
3. An Access Policy which defines access rights and privileges to
protect assets from loss or disclosure by specifying acceptable
use guidelines for users, operations staff, and management. It
should provide guidelines for external connections, data
communications, connecting devices to a network, and adding new
software to systems. It should also specify any required
notification messages (e.g., connect messages should provide
warnings about authorized usage and line monitoring, and not
simply say "Welcome".
4. An Accountability Policy which defines the responsibilities of
users, operations staff, and management. It should specify an
audit capability, and provide incident handling guidelines
(i.e., what to do and who to contact if a possible intrusion is
detected).
5. An Authentication Policy which establishes trust through an
effective password policy, and by setting guidelines for remote
location authentication and the use of authentication devices
(e.g., one-time passwords and the devices that generate them).
6. An Availability statement which sets users' expectations for the
availability of resources. It should address redundancy and
recovery issues, as well as specify operating hours and
maintenance downtime periods. It should also include contact
information for reporting system and network failures.
7. An Information Technology System & Network Maintenance Policy
which describes how both internal and external maintenance
people are allowed to handle and access technology. One
important topic to be addressed here is whether remote
maintenance is allowed and how such access is controlled.
Another area for consideration here is outsourcing and how it is
managed.
8. A Violations Reporting Policy that indicates which types of
violations (e.g., privacy and security, internal and external)
must be reported and to whom the reports are made. A nonthreatening
atmosphere and the possibility of anonymous
reporting will result in a greater probability that a violation
will be reported if it is detected.
9. Supporting Information which provides users, staff, and
management with contact information for each type of policy
violation; guidelines on how to handle outside queries about a
security incident, or information which may be considered
confidential or proprietary; and cross-references to security
procedures and related information, such as company policies and
governmental laws and regulations.
There may be regulatory requirements that affect some aspects of your security
policy (e.g., line monitoring). The creators of the security policy should consider
seeking legal assistance in the creation of the policy. At a minimum, the policy
should be reviewed by legal counsel.
Once your security policy has been established it should be clearly communicated
to users, staff, and management. Having all personnel sign a statement indicating
that they have read, understood, and agreed to abide by the policy is an important
part of the process. Finally, your policy should be reviewed on a regular basis to see
if it is successfully supporting your security needs.