DoD 8570 seeks to accomplish the following objectives:

1. Create standards whereby IA Workfoce personnel, at all levels and fuctions, obtain a uniform level of competency with regard to DoD information and networks.
2. Establish a minimum skill level for all IA Workforce personnel throughout the DoD.
3. Provide qualified IA Workforce members to the soldiers that need them.
4. Creation of a set of formal training requirements and establishment of certification programs.
5. Add to the knowledge base of every IA Workforce team member through education or experience.

DoD 8750 document can be found here while DoD 8750 training and assessment can be reached at GIAC/DoD8750.

This article is ripped and modified from http://dod8570.net/

Formally: ISO 20000-1 (‘part 1′) “promotes the adoption of an integrated process approach to effectively deliver managed services to meet the business and customer requirements”. It comprises ten sections:

• Scope
• Terms & Definitions
• Planning and Implementing Service Management
• Requirements for a Management System
• Planning & Implementing New or Changed Services
• Service Delivery Processes
• Relationship Processes
• Control Processes
• Resolution Processes
• Release Process.

ISO 20000-2 (‘part 2′) is a ‘code of practice’, and describes the best practices for service management within the scope of ISO 20000-1. It comprises the same sections as ‘part 1′ but excludes the ‘Requirements for a Management system’ as no requirements are imposed by ‘part 2′.

ISO 20000, like its BS 15000 predecessor, was originally developed to reflect best practice guidance contained within the ITIL (Information Technology Infrastructure Library) framework, although it equally supports other IT Service Management frameworks and approaches including Microsoft Operations Framework and components of ISACA’s CobIT framework. It comprises two parts: a specification for IT Service Management and a code of practice for service management. The differentiation between ISO 20000 and BS 15000 has been addressed by Jenny Dugmore.

The standard was first published in December 2005.

Taken From : http://en.wikipedia.org/wiki/ISO_20000

These two complementary sets of best practices deal, respectively, with service management and with governance in IT organizations. Between them, the ITIL and CobiT provide guidelines to help companies cut support costs, increase IT efficiency, and meet regulatory requirements.

The ITIL was developed by the British government in the 1980s as a best practice framework for IT service management. It is vendor-independent, and the Crown still holds copyright to ensure no organization can hijack the framework for its own purposes. It really is a library, too, originally consisting of over forty individual volumes, each one dedicated to a separate area of service management. ITIL Service Management is currently embodied in the ISO 20000 standard (previously BS 15000).

Those forty-odd books have since been distilled into a more manageable seven (and will soon be down to five, in ITIL version 3), consisting of volumes on:

* Service Support.
* Service Delivery.
* Planning to Implement Service Management.
* ICT Infrastructure Management.
* Applications Management.
* Security Management.
* The Business Perspective.

Each volume in subdivided into sections breaking down its topic further. For example, Service Support is divided into:

* Service Desk: How to establish and run a service desk as the central point of contact with the user.
* Incident Management: Restoring normal operations as quickly as possible.
* Problem Management: Diagnoses root causes of incidents reported by the service desk and arranges changes in the IT infrastructure to prevent their recurrence.
* Change Management: Processes and procedures to ensure prompt and efficient handling of changes.
* Release Management: Planning of changes so both IT and non-IT aspects are considered.
* Configuration Management: Identifies, controls, and maintains the configurations of items and services.

And Service Delivery is divided into:

* Availability Management: Maintaining the availability of services that allow the business to function effectively.
* Capacity Management: The process for predicting future needs.
* IT Service Continuity Management: Managing the ability to provide pre-defined levels of service after a disaster or other business interruption.
* Service Level Management: Agreeing upon, monitoring, and reporting IT achievements and establishing ways to eliminate poor service.
* Financial Management for IT Services: Budgeting, accounting, and charging for IT services.

Each book provides processes and vocabularies, so every ITIL-certified individual can describe situations in the same way, and understand precisely what?s going on. This is particularly valuable in situations where several IT organizations are being merged.

Yes, I did say certified. Independent examining bodies provide several levels of certification for ITIL practitioners, from the very basic Foundation Certificate to advanced management. And certification implies training, such as that provided by the improbably-named Pink Elephant, a global leader in all things ITIL, ITIL Training World, which offers online courses, and even IBM Global Services.

ITIL best practices have been rolled into many commercial products. Remedy help desk and CA Unicenter are compliant, for example, and Microsoft has adopted the framework as well, and in fact uses it in-house.

Where ITIL concentrates on service delivery, CobiT looks at governance. It is, according to its Web site, “an IT governance framework and supporting toolset that allows managers to bridge the gap between control requirements, technical issues and business risks. COBIT enables clear policy development and good practice for IT control throughout organizations.” It was developed by the ISACA (Information Systems Audit and Control Association) and the IT Governance Institute (ITGI) in the 1990s, and is now in its fourth edition.

CobiT’s framework is built on four domains (Plan and Organise, Acquire and Implement, Deliver and Support, Monitor and Evaluate) with 34 high-level control objectives, which are in turn broken down into detailed control objectives. The primary IT governance focus areas in CobiT are as follows:

*Strategic alignment focuses on ensuring the linkage of business and IT plans, on defining, maintaining and validating the IT value proposition, and on aligning IT operations with enterprise operations.

*Value delivery is about executing the value proposition throughout the delivery cycle, ensuring that IT delivers the promised benefits against the strategy, concentrating on optimizing costs and proving the intrinsic value of IT.

*Resource management is about the optimal investment in, and the proper management of, critical IT resources: processes, people, applications, infrastructure and information. Key issues relate to the optimization of knowledge and infrastructure.

*Risk management requires risk awareness by senior corporate officers, a clear understanding of the enterprise’s appetite for risk, transparency about the significant risks to the enterprise, and embedding of risk management responsibilities into the organization.

*Performance measurement tracks and monitors strategy implementation, project completion, resource usage, process performance and service delivery, using tools such as balanced scorecards that translate strategy into action to achieve goals measurable beyond conventional accounting.

CobiT, like ITIL, comes with the possibility of certification, although it currently only has a foundation level of certification available. Training consists of two online, self-paced courses; there’s a newly-minted third course specifically dealing with Sarbanes-Oxley. Information on CobiT education can be found here.

Where do ITIL and CobiT fit into the business IT world? ITGI positions CobiT as a better alternative to ITIL and other frameworks in its 2004 paper, CobiT Mapping Overview of International IT Guidance, but IT service management guru Malcolm Fry thinks that each of the two brings an important component to the table. In a 2005 interview in IT Business Edge, Fry said, “The ITIL is basically running the day-to-day operations of IT. What CobiT does is it brings in check points, security points, so in other words, in a certain point in the procedure you can’t go past here unless you’ve got authority or proof or you meet some kind of criteria. So when you’re implementing ITIL to support the corporate TQM, then CobiT you will implement at the same time to put the control points in.”

Taken From : http://business.itbusinessnet.com/articles/viewarticle.jsp?id=51745-1

How secure is your company’s information? In this age of distributed computing and of client-server and Internet-enabled information access, computer security consistently rises to the top of most “important issues” lists.

To answer this question with certainty is difficult. There are no absolutes with security. An important first step for most corporations is a security policy that establishes acceptable behavior. The next, and more critical step, is to enforce that security policy and measure its effectiveness. A security policy is in tension with user convenience, creating forces that move security practices away from security policy. Additionally when new machines or applications are configured the security related issues are often overlooked. Therefore the gap between central policy and decentralized practice can be immense. These are significant tasks, as are identifying problems and taking corrective action on a constantly changing network. Many enterprises typically fall back on blind faith rather than wrestle with the fear of the unknown.

Sources of Risk

In order to assess your true security profile, you must first understand the sources of risk. The most infamous risk is embodied by the external hacker accessing a corporate information systems via the Internet. Traditionally these hackers view breaking into a system as

mountain climbers view scaling a cliff, for them its the next great challenge. However, as ever increasing numbers of corporations interconnect their information systems successful break-ins become commercially rewarding. Practitioners of industrial espionage now view the computers on the Internet as valuable potential sources of information. Often these “professionals” masquerade as the traditional hacker to disguise their true purposes.

Although the threats from external attacks are real, they are not the principle source of risk. FBI statistics show that more than 60% of computer crimes originate inside the enterprise. These risks can take multiple forms. Unscrupulous employees may be searching for organizational advantages. A disgruntled employee may be co-opted by an industrial espionage agent. Increasingly corporations are turning to contractors for specialized skills or to absorb temporary increases in work-load. These contractors are often given access to the corporate information system and thus they can also present a risk to corporate information.

Lines of Defense for the Corporate Information System

• Firewalls

Many enterprises erect a firewall as the first and often only line of defense for their information systems. A firewall is a device that controls the flow of communication between internal networks and external networks, such as the Internet. Many corporations assume that, once they have installed a firewall, they have reduced all their network security risks.

A firewall must be configured to allow or deny appropriate traffic. The configuration process can be highly susceptible to human error. In a dynamically changing environment, system managers routinely reconfigure firewalls without regard to security implications. Access control lists on a firewall can be numerous and confusing. You must be sure that the firewall has been set up correctly and that it is performing well.

• Internal Defenses

Even when properly configured the firewall can only repel connection attempts that come through the firewall itself. This represents the logical equivalent of the Maginot line that defended France’s border with Germany before World War II. The forts and defenses of the Maginot line were impenetrable; however, an attack around the line through other neighboring countries completely circumvented the line. The attackers were able to easily move through the rest of the country because the French defense efforts had been focused on the Maginot line. A information attack can be mounted via modem on the internal network. If all of the enterprise’s defenses are focused on the firewall then an attack that circumvents firewall though a modem or an internally based attack will have free reign over the information systems.

Thus the security features of the internal computers must also be employed. The important balance between convenience for the users and security concerns must be considered. That is the computer systems must be allowed to be collaborative in nature with appropriate access to information and functions across systems. At the same time this access provides a wide open avenue for the industrial espionage attack.

Often the elements of the enterprise’s computer system must be updated to eliminate security risks introduced by bugs in operating systems and network service programs. If a bug creates a performance related problem then it is a “squeaky wheel” that will drive the upgrade. A functioning version of a program or service with the security bugs can be easily overlooked as an important item for upgrades. By the time a security related bug becomes the proverbial “squeaky wheel” – its too late.

Assessing IT Security

Security must be assessed from multiple viewpoints for the best over all picture. These perspectives range from the physical security of the machines to the configuration of the firewalls to the trustworthiness of workers. The history of industrial espionage has been in the physical world and thus numerous practices have been developed to handle the this portion of security assessment. The age of network based industrial espionage has a brief history and thus less developed security assessment practices.

The security profile of a network of machines can be assess from three principle vantage points.

1. From the outside of the Enterprise – the view of the computer infrastructure through the firewall
2. From the inside of the Enterprise – the view of computers from behind the firewall
3. From the computer keyboard – the view from the actual operating system of the individual machine itself.

Each of these perspectives will reveal unique security vulnerabilities. Removing the vulnerabilities as seen from outside the enterprise is the first step to halt the efforts of the casual hacker and industrial espionage age. Removing the vulnerabilities as they appear from behind the firewall accomplishes two goals. It creates a second line of defense should the firewall become compromised. It also creates a defense for the “blitzkrieg” attack around the firewall through a modem or other non-protected entryway. Finally evaluating security from the machines themselves will close vulnerabilities that could be exploited through a firewall or from other machines on the network. It also hardens the security of the machines, restricting the avenues of attack for the disgruntled worker or the co-opted contractor.

Assessment Strategies

• The Ideal Strategy

The ideal assessment strategy begins with the individual machines before they are ever inter-connected. Each machine’s vulnerabilities are corrected, putting the network of machines off to a reasonable start. Next the network of computers are probed for security vulnerabilities. Typically the move from individual machines to an internetwork of interdependent machines creates a significant number of exploitable holes. Thus the network of computers is examined for security vulnerabilities. Finally the external network defenses, the firewall, are verified. In this final stage the last layer of defense – the first layer encountered by an information adversary – can be thoroughly checked. Problems are more easily isolated to the configurations and performance of the firewall connections themselves.

• Pragmatist strategy

In real life the machines, the internetwork of computers and often the external connections to the Internet already exist. Additionally a significant number of vulnerabilities exist at each level of the enterprise’s information systems. Often the number of known vulnerabilities exceeds an organization’s capacity to implement corrective action. This imbalance between known vulnerabilities and corrective capacity is a chief contributor to the gap between an enterprise’s security policy and security practice. An enterprise in this position often does not care to learn of more security vulnerabilities, following a “what I don’t know won’t hurt me” philosophy.

The real danger in this situation is that the scarce resources available to implement corrective security policies are squandered on the most well know vulnerabilities instead of being allocated to the vulnerabilities with the greatest risk to the enterprise. Firms in this position should invest in knowledge so that their limited resources are optimally deployed. The first step in a resource investment decision to is fully understand the range of options available and then pick the portfolio of investments that presents the highest aggregate return. In security assessment the firms must first evaluate all the vulnerabilities from all perspectives: system, internal and external. Aggregating and prioritizing the list of vulnerabilities will then provide a guideline for investing in corrective action to improve the match between security practice and security policy.

Continuous Security Improvement

As individual vulnerabilities are corrected under any security improvement process these vulnerabilities should stay fixed. Thus the corrections must always to monitored. By monitoring these changes over time the firm can look for the root causes of frequently occurring vulnerabilities. Then the enterprise can move on to lower priority vulnerabilities.

By undertaking a strategy of consistently fixing vulnerabilities, monitoring them to make sure they stay fixed and analyzing the causes of recurring vulnerabilities the enterprise enters the mode of continuous security improvement. The feedback loop of a security assessment provides the information flow necessary to improve the security of the enterprise’s information systems

SUCCESSFUL SECURITY ASSESSMENT PRACTICE

To be the successful the security audit must be thorough, it can not leave out possible vulnerabilities. It must also be repeatable to provide a consistent perspective on the firm’s security practice. By its very nature a security assessment will initially increase the workload for an MIS department. These seemingly conflicting goals can be met through the use of a security audit tools that can provide thorough and repeatable process with an effective means of implementing corrective actions.

SAFEsuite(TM) – the comprehensive family of network security assessment tools designed to audit, monitor and respond to all aspects of your enterprise network security. Specifically designed to assess a variety of network devices, SAFEsuite tests for security vulnerabilities found and exploited in web sites, firewalls, operating systems and networked UNIX(R) and Windows NT(TM) hosts and workstations. It scans for the most comprehensive set of security vulnerabilities and provides you with the power and flexibility to assess all aspects of your network security policy. SAFEsuite also provides your system administrator with the added ability to monitor your networks in real time. With RealSecure, you can detect, alert and stop all unauthorized activity on your network.

WEB SECURITY SCANNER(TM)

Web Security Scanner tests the configuration of the Web server, evaluates the security of the underlying file system, searches for CGI scripts with known vulnerabilities and attempts to exploit custom CGI scripts.

Web Security Scanner traverses the HTML directory structure scanning for HTML links, Java, Java scripts and CGI links. Each link is followed in the HTML directory structure and any new links are added to the cached file. If the local link cannot be resolved it is noted for the user. Each subdirectory is checked to see if a GET request returns an index as expected or returns an entire directory listing. If the directory listing is returned, it is flagged as a vulnerability.

Web Security Scanner examines CGI scripts for the existence of the following potentially vulnerable executables:

• finger
• phf
• test-CGI
• sh
• csh
• perl
• bash
• tcsh

These services are tested for possible exploits by Web Security Scanner and any vulnerabilities are reported.

Custom CGI scripts are also tested for holes that allow execution of unauthorized commands that could lead to compromise of the server.

The Web Security Scanner identifies the existence of Private HTML pages that are password protected. It then does a Bruteforce account and password check to identify easily guessed or default passwords. Any cracked passwords are identified as vulnerabilities.

The Web Security Scanner checks for versions of http servers that are known to be vulnerable such as NCSA 1.2 and 1.3.

FIREWALL SCANNER(TM)

Firewalls are an important component of network security, but many organizations assume that they are adequately protected because they employ a firewall. However, a firewall must be correctly configured to provide effective protection. Firewall Scanner has added a number of firewall security checks to the base Intranet Scanner tests, including source porting, source routing, SOCKs, TCP sequence prediction (IP spoofing), and Denial of Service Attacks.

Source Porting

Filter rules typically are based on source and destination port addresses. A TCP/IP-enabled machine has 65,535 possible virtual ports; some of them are defined for certain services; for example, e-mail is port 25. When one machine FTPs to another and wants to transfer a file back from the FTP server, typically the server opens source port 20 to connect to the FTP client and transfer data. Therefore, many firewalls allow source port 20 into a network. An intruder can modify telnet to make the connections come from source port 20, thereby penetrating the firewall. Firewall Scanner checks to see if source port 20 is allowed to connect to the network.

Source Routing

Source routing is an IP protocol option that allows you to define how packets are routed. When source routing is on, many firewall filter rules are often bypassed. Many router-based firewalls allow source-routed packets to pass. Many hosts have source routing built into the kernel and do not allow it to be turned off. Firewall Scanner assesses susceptibility to source-routed packets.

SOCKS

SOCKs is a library of proxy-application firewalls designed to allow certain services through and keep intruders out. The fundamental problem with SOCKs is the same as with many security tools: SOCKs is often misconfigured. Often the administrator establishes rules to allow certain services through the firewall, but the rules necessary for denying access to intruders are never implemented. Consequently, services seemingly work fine with the firewall, but the firewall’s inability to keep intruders out is not recognized until an intruder breaks through. Even then, the cause of the problem may never be recognized. Firewall Scanner attempts to connect to important services through the SOCKs port, to see whether filter rules have been configured properly.

TCP Sequence Prediction

TCP sequence prediction, or IP spoofing – the technique that Kevin Mitnick used to break into many networks across the Internet – tries to trick a host that trusts another host. For example, if host A and host B are in a corporate network and host A is trusted by host B, then host A is allowed to log into host B based on this trust, without a password. An intruder who can make his host C look like host A will also be able to log into host B. Firewall Scanner determines a firewall’s vulnerability to IP spoofing.

Direct RPC Scan

The portmapper is a service, such as NIS, that allows you to identify the ports on which the RPC (Remote Procedure Commands) reside. Many filter-based firewalls may block the portmapper on port 111. The RPC commands themselves remain in place on various machine ports. It usually is hard to determine where the services are if the portmapper is blocked. However, if an intruder scans directly for the RPC services, the intruder could bypass this type of security. Firewall Scanner scans directly for the RPC services to determine whether they are exploitable.

Stealth Scanning

In stealth scanning, an intruder does not attempt to establish a connection, but rather uses packets at a low level with the interface. These low level packets elicit different responses depending on whether or not a port is active. This technique allows TCP port scanning many times faster than a regular connect routine on UNIX and does not trigger alarms built into many SATAN detectors and tcp_wrappers. While many firewalls block particular packets that would establish a connection, Firewall Scanner’s stealth scanning packets do not attempt to establish a connection; therefore, they can bypass firewall security and identify services running on an internal network.

Denial Of Service

A denial of service attempts to force the firewall into a failure condition, typically forcing a reboot of the machine. As an example, flooding a machine with sync packets or connections attempts can cause an overflow condition in buffers and log files. At this point the firewall can cease operation and close all connections, it can continue operations while stopping the logging operations or it can continue operations in a more open environment. Firewall Scanner has a battery of denial of service attacks to assess a firewall’s durability.

Intranet ScannerO

Intranet Scanner assesses security from the TCP/IP services perspective. It learns your network and systematically probes each network device for security vulnerabilities. Network devices might include a UNIX host, a Microsoft NT/Windows 95 system, a router, a web server, and even an X terminal. Network security is only as strong as the weakest link. Administrators may try to protect only machines that hold sensitive information. Intruders know this and look for machines that might not be protected, such as infrequently used print or fax servers. Then, once in the network, an intruder can set up sniffers to capture sensitive data, such as passwords, going over the internal network. If the intruder is using a machine that is already part of the internal network, sniffing and trust relationships usually allow springboarding into access to sensitive machines. An administrator does not have time to identify the devices on the network that actually could be used as springboards. Intranet Scanner can quickly find these weak links and identify the vulnerable services.

Brute force Attacks

Many networked machines are shipped with default accounts that allow an administrator to gain immediate access to a machine and to configure it. If the administrator doesn’t change the defaults, an intruder can use them to gain access to the network. When the administrator adds accounts to a machine, those accounts may get installed with an easy password. A brute force attack against a machine looks for common defaults and known accounts that might be vulnerable. If a default or login account becomes compromised, the services telnetd, ftpd, rsh, and rexec allow access to a machine. Intranet Scanner performs, through these services, brute force tests for default and vulnerable accounts.

Anonymous FTP

Anonymous FTP is a service that allows the easy transferring of files. The FTP server has many configuration issues. An improper configuration could allow unauthorized access to the rest of the machine. Intranet Scanner checks for these configuration flaws and determine whether the FTP site is vulnerable.

Networked File Systems

NFS allows many machines to have a virtual hard drive that operates over the network. If improperly configured, NFS may allow anyone to access this virtual hard drive. An intruder could then copy, modify, and possibly delete critical data from the NFS, and even gain full access to the machine. Intranet Scanner finds misconfigured NFS servers.

File Sharing

Windows NT and Windows 95 use a service called file sharing that allows for sharing files between networked computers. Unfortunately, many people do not realize that this may also allow access to their computers by anyone on the Internet. Intranet Scanner finds misconfigured file-shared machines and allow the administrator to take corrective action.

Rexd

Rexd, an old service from when UNIX was first being networked, was not developed with security in mind. It has little or no authentication to stop intruders from gaining access to a network. Intranet Scanner discovers this service. The administrator can then remove it from the machines on the network.

Rsh and Rlogin

Both Rlogin and Rsh vulnerabilities give an intruder instant access to the machine. The Rlogin vulnerability affects AIX and Linux machines. It allows anyone to rlogin as root without a password. An intruder issuing the command rlogin hostname.com -l -froot sees the login banner and a shell. Intranet Scanner locates these vulnerable services and enable the administrator to take corrective action.

X windows

Many users have xhost + in their configuration file. This permits access to the
X Display by anyone, anywhere. An intruder who can access the X Display can obtain keystrokes and remotely execute commands as the user running the
X Display. It is possible to configure the xhost to authorize only certain hosts, but even then any user from those remote hosts can use the X Display to compromise data. Intranet Scanner detects vulnerable X Displays.

System security ScannerO

System Security Scanner completes the computer network security assessment triangle by evaluating the security profile of individual hosts from the operating systems (OS) perspective. System Security Scanner checks for file ownership and permissions; OS configurations; Trojan Horse programs; and signs of a hacker’s presence. System Scanner allows the administrator to automate the process of eliminating security vulnerabilities.

File ownership and permission tests

There are many potential vulnerability problems where the files are not owned by the proper accounts or the permission may not be set up correctly. There are two types of tests to check for:

1. Have a list of known permissions for certain files and directories, including home directories.
2. Build a baseline specific for the machine being tested and compare and contrast this library with future assessment tests of the machine.

Configuration and access file tests

Many system files can configure the machine insecurely and need to be checked. Users have certain files that allow access from certain services, these configurations should be checked against the security policy.

MD5 Signaturing

The best known method for checking if a file has the correct data content is through a md5 signature test. This digital signature is like a fingerprint. A database of fingerprints of good and bad programs can detect which files have been modified or which ones need to be upgraded to the latest version. There are three types of MD5 checksums tests to be considered:

1. List of filenames with the good checksums and bad checksums to identify whether the machine is currently up to date.
2. A list of only bad checksums and filenames that signify vulnerable versions of binary programs. This is for programs that do not have a specific location, such as a web browser.
3. A baseline of md5 checksums for the machine currently being tested so that future scans can contrast the checksums to look for modifications to the machine’s important files.

Hacker specific testing

There are certain things that a hacker may do that can be detected. Checking if the machine is in promiscuous mode can detect whether a hacker is sniffing from that machine and catching passwords going across the network. There are also certain directories that hackers place files in that should be checked for odd files.

Taken From :http://www.windowsecurity.com/whitepapers/Comprehensive_Computer_Network_Security_Assessment_.html

First, we must define what we mean when we say policies are “effective.” One way to build this definition is by looking at the ways organizations feel their policies are not effective. For this discussion, we use the following criteria:
1. Effective policies adequately define the high-level security goals of the company to reduce operational risk.
2. Effective policies adequately protect an organization against legal action for possible violations.
3. Effective policies are read and understood by all employees and contractors in various roles within the organization.

Criteria #1 is based on the need for policies to be complete. An organization’s policies must adequately cover the topics of an effective security program, including compliance with regulations.

Criteria #2 reflects the organization’s fear of damaging lawsuits, including possible violation of legislation. In fact, these fears are justified. Recent court cases are establishing precedents that would in fact hold most organizations liable.

Criteria #3 reflects most organizations highest concern when it comes to security. In fact, these three criteria are intricately related, and it is virtually impossible to adequately satisfy one without the other two.

Ten Steps to Effective Policy

In the following steps, we will discuss how each relates to the effective policy attributes listed above. One reference we make is to the guidelines of the US Sentencing Commission and the Office of Inspector General. They have defined seven elements for measuring if a breach in compliance has occurred. Another common reference we make is to ISO/IEC 17799, the international standard for security code of practice. We also provide tips within each section to help organizations achieve these goals.

1. Pick a standard structure for your policy documents

The policy development process is extremely challenging. Not only because of the subject matter, but because of the various personnel required to create, update, review and approve them. When done properly, policies follow a standard structure and are updated on a regular basis. Policies should include basic items such as effective date, responsible party, scope, exception reporting, and enforcement. The best way to encourage this is through a standard policy template used consistently throughout the organization. If our goal is to create a consistent security message that is read and understood by each member of the organization, the easiest way to fail is to have multiple different document types in different formats and in different places. (Only you know if this is true of your organization!)

A great way to help this process is to define three types of documents: Policies, Standards and Procedures. Policies are high-level statements that should remain relatively consistent over time. Standards, on the other hand, are the detailed items that enforce a high-level policy. Standards can be authored by department managers or IT staff, and can change more frequently. Procedures are the detailed steps that individuals will follow to implement the standards. This simple structure can be referred to as a “Policy Governance Structure” and can greatly reduce the simplicity of your security policy process.

This structure provides another great advantage that we will discuss in the area of monitoring compliance. By documenting procedures and standards in separate documents, organizations can easily map these business requirements against the security tools they monitor for compliance. Most security technologies, including firewalls, access control and vulnerability assessors are not designed to enforce a policy. They are designed to enforce a specific technical control on a particular platform.

2. Write it all down

Step #1 leads directly to the second requirement – making sure that you formally document all of your policies, standards and procedures. This requirement is either explicitly or implicitly stated in many security frameworks and regulatory requirements. The HIPAA Final Security Rule, for example, requires that policies and procedures are documented, and that these documents be kept for at least 7 years. The first “key control” of the ISO 17799 policy framework is to have a written security policy that is accessible to all employees.

The guidelines from the US Sentencing Commission note that an organization must have “documented” architecture of policy, operational, and technical controls. It sounds simple, but how can you validate compliance if you don’t know what you are validating against?

If you don’t have written policies, a good resource is Information Security Policies Made Easy, by Charles Cresson Wood. This resource contains over 1500 pre-written security policies covering all the domains of ISO 17799.

3. Assign responsibility for various security roles

This is another area where regulatory requirements are clear. It is critical that you identify and document key individuals who are responsible for various operational security roles.

For example, which high-level executive is sponsoring your security program? Which team or individual is responsible for updating security policy documents? Which team or individual is responsible for responding to security incidents? Most security or audit frameworks such as ISO 17799 and COBIT have clear requirements for assigning securityresponsibilities in these areas. However, if you don’t document these, it is unlikely you will be able to prove that these roles actually existed. Imagine a trial lawyer asking for evidence that you were serious about security within the company. What document would you produce? How many times have you seen a policy document that has an “author” who is no longer with the company?

If you don’t have documented security roles, a good resource is Information Security Roles and Responsibilities Made Easy, by Charles Cresson Wood. This resource has pre-written job descriptions and reporting relationships that you can easily customize.

4. Use a security framework

This item relates to Criteria #1 of completeness. Security frameworks are an organized set of security requirements, usually broken down into numerous categories or domains. Fortunately, there are a number of these available. For example, ISO-IEC 17799:2005 provides a framework of ten security domains. The Information Security Forum Standard of Good Practice is another framework similar to ISO. For federal governments, the National Institute of Standards provides a framework for evaluating security in 17 key topic areas. NIST also provides guidance on how to measure effectiveness in each of these categories.

Security domains provide a benchmark for measuring the completeness of your policy program. Once again, if your goal is  completeness – how can you measure progress against your goal?

5. Do risk assessments and have an exception process

Risk assessments are another key to effective policies. First, your policies should document when and how risk assessments are performed. In addition to being a foundation of most security programs, risk assessments allow organizations to define what levels of control are appropriate for their organization. If you look into the language of most security regulations, you see something like:

“administrative, technical, and physical safeguards appropriate to the size and complexity of the [bank] and the nature and scope of its activities.” – Gramm-Leach-Bliley Act

For example, the HIPAA Final Security Rule has a number of “required” and “addressable” controls. Addressable controls are deemed optional providing that an organization document that they performed a risk assessment and why they chose not to implement a particular control.

Once again, imagine facing the trial attorney who is asking that you document that your organization followed “due care” in your security program. Would a formal risk assessment help?

Key to this process is a “Risk Acceptance Memorandum.” This is a simple form that documents who is accepting the risk, how long the exception should last, and what mitigating controls are in place. Sample risk acceptance memos are widely available on the internet.

6. Communicate your policies regularly

This requirement would be the “Achilles Heel” of policy. You have heard it by various names including “shelfware” and “policies collecting dust.” And yet precedent after precedent shows that this is key to any policy program. For example, a number of lawsuits have been filed and won by employees who were fired for security policy violations. When the court looked at the data, they found that the companies rarely or never communicated their policies to employees in the company.

In a recent lawsuit against a large public company, the court ruled that a simple email notification was not sufficient to notify employees of a change in policy. In fact, employees must acknowledge the receipt of this notification and demonstrate that they have some understanding of how the changes would affect them.

The Federal sentencing guidelines are clear on this point. Organizations must communicate compliance program requirements effectively, and employees and business partners must be aware of their role in complying with laws and policies. This is a key point: employees and partners must be aware of their role in security and compliance.

Communicating is not only required for your policies to be enforceable, is addresses the key area of security awareness. What better way to create security awareness than to educate your users on your own policies? Again, security-related regulations are clear on this point. For example, the HIPAA Final Security Rule requires security awareness and training in

[...organizations must] “Implement a security awareness and training program for all members of its workforce (including management).”
- HIPAA

7. Enforce consistently

Policies should document the process of enforcement, including who is responsible for enforcement. Policies should also be enforced consistently. Holding employees responsible for security, but given exemptions to senior executives is a common practice. Not only does this send a bad message to employees, but it will unravel your compliance program. The Federal sentencing guidelines state that “controls [policies] must be uniformly applied in the organization as they support compliance objectives.”

Again, imagine yourself in front of the trial attorney, providing documentation that you have consistently enforced your policies. The first document would be your documented sanctions policy, and then the audit log which shows that every employee in the company understands what might happen in the event of a security violation.

8. Include incident response

Policies should define the organizational goals and responsibilities for incident response. Most organizations will experience security incidents, and the level to which they respond and recover can have serious impact on their business. Not only is incident response a key element of security frameworks, most legislation that defines security requirements has specifics about incident response.

Incident response policies should not only define what an incident is, but they should clearly define how incidents should be reported and handled. Guidelines should be established on when and how incidents should be report to law enforcement. Once again, critical parts of your incident response policy should be communicated to employees and business partners.

A question to ask yourself is this: Would your employees know how and where to report a security incident?

9. Audit your policies for compliance

Your entire policy framework should be designed around the concept of auditing. Once again, performing security audits is a key part of security and regulatory frameworks. “Compliance” is the tenth key domain from ISO 17799, and includes action items like “reviewing security policies and technologies for legal and technical compliance.” But what are you auditing against? The answer is your stated policy.

When you write a policy, you should consider what evidence would support an audit of this policy. For written policies, it may simply be the written document. When you create a standard or a procedure, it is a good idea to create the “test case” for that procedure. While auditing can be done easily on certain technologies, the questions get a bit trickier when we involve the human elements of security. For example, how can I verify that every employee in my organization has read and understood our security policies? Do I have evidence or an audit trail to support this?

10. Use automation for enforcement and auditing

As you consider all that is required for an effective policy program, you quickly realize that doing all of this “by hand” is nearly impossible. For example, how can I distribute my policy documents to every user in a company of 5,000 employees, and then demonstrate that they have read and understood them? Similarly, how can I verify that all of my Windows and Unix systems are enforcing my stated password and automated logoff standards? The only effective way is through automation.

This is an area where recent developments in automated policy tools can help. New intranet based tools, such as VigilEnt Policy Center from NetIQ Corp., can actually target individual policy and procedure documents at various individuals based on their organizational role. Management reports organize and track who has read and acknowledged policy documents by department or role. These tools provide detailed audit logging of which policies were effective on which dates, and who signed off on which policies. Thinking like an auditor, these tools provide a great way for organizations to demonstrate compliance with training and awareness requirements.

On the technology side, there are numerous host-based vulnerability assessment tools that can verify the security settings on your various platforms. This is where the organization of your documents is key: If you define detailed standards in a separate document, you can easily verify that the controls (i.e. the individual machine settings that enforce these standards) match what is written in your documents.

Summary

Security policies form the foundation for your security and compliance programs. However, having written policies is not enough. Policies must possess certain criteria if they are to be effective in reducing organizational risk. Following these steps will dramatically increase your ability to defend yourself in both audits and possible lawsuits relating to information security.

Taken From : www.informationshield.com/papers/

ISO/IEC 27002 provides best practice recommendations on information security management for use by those who are responsible for initiating, implementing or maintaining Information Security Management Systems (ISMS). Information security is defined within the standard in the context of the C-I-A triad:

The preservation of confidentiality (ensuring that information is accessible only to those authorised to have access), integrity (safeguarding the accuracy and completeness of information and processing methods) and availability (ensuring that authorised users have access to information and associated assets when required).

the standard contains the following twelve main sections:

1. Risk assessment
2. Security policy – management direction
3. Organization of information security – governance of information security
4. Asset management – inventory and classification of information assets
5. Human resources security – security aspects for employees joining, moving and leaving an organization
6. Physical and environmental security – protection of the computer facilities
7. Communications and operations management – management of technical security controls in systems and networks
8. Access control – restriction of access rights to networks, systems, applications, functions and data
9. Information systems acquisition, development and maintenance – building security into applications
10. Information security incident management – anticipating and responding appropriately to information security breaches
11. Business continuity management – protecting, maintaining and recovering business-critical processes and systems
12. Compliance – ensuring conformance with information security policies, standards, laws and regulations

Within each section, information security controls and their objectives are specified and outlined. The information security controls are generally regarded as best practice means of achieving those objectives. For each of the controls, implementation guidance is provided.

Reference : http://en.wikipedia.org/wiki/ISO_17799