The following is a document that provides an example of an IT Security policy framework that explains the necessary steps when establishing good security protocols for a company. The following is an imaginary company called The Company. Please read the introduction for a better understanding of the document.

Introduction

This architecture document outlines a framework for creating and maintaining a secure operating environment for The Company. The overall goal of this framework is to define requirements for maintaining confidentiality, integrity, and availability in the company's business processes and information systems. This document does not outline the exact procedures for managing systems; instead, it specifies a set of considerations that should be made when making business decisions in order to maintain competitiveness, preserve the company's reputation, comply with any applicable regulations, and generate shareholder value.

1. Security Control Families

1.1 Perimeter Defense

1.1.1 Firewall Rules and Filters

Establishing a good perimeter is key when securing any company. To start, one must setup firewalls at all network border (perimeter) locations. Each firewall should be customized upon the area it resides. Thereby, it should restrict traffic on a host-by-host and service-by-service basis. In order to maintain with standards that are considered best practices, one must deploy multiple DMZs and place servers behind said location, test firewall rules in case of an exploit of a Denial of Service attack, and restrict all connectivity in regards to the DMZ. (Tipton 2010)

 

At each office location, maintain deployment of network-level access controls and continue to test each frequently. As mentioned earlier, segmentation of multiple DMZs is necessary in order to take heed against attacks against Internet-accessible resources (such as the external webserver, etc.). With that being said, it is important to regularly monitor and maintain firewall policies, and to eliminate anything that is deemed antiquated. (Tipton 2010)

 

In regards to user specific limitations and DMZ/firewall policies, it is imperative to limit direct on-bound connectivity into DMZs in the core network. Only administrators of the network should be allowed access into such access locations. (Tipton 2010)

 

All firewalls will be host-based within The Company Inc., and all clients, employees, etc. must have a software firewall that is approved by the company in order to be granted access on the network (this being one element among other criteria before allowed access onto the network). (Tipton 2010)

1.1.2 Antivirus (Desktops and Servers)

Desktops (includes laptops and any approved mobile device): Every device that connects to the network must be first approved by the IT department for The Company Inc. Upon receiving a desktop or laptop unit (at this level), all said devices must be appropriately configured with automatically updating pre-bundled approved anti-virus/anti-malware software that monitors all in-bound and out-bound user traffic. All virus definitions must be kept up-to-date and synchronized appropriately. (Tipton 2010)

 

Any mobile device that connects to the network must be on the approved network device list and must uphold to these standards; otherwise, all traffic will be blocked.

 

Servers: As mentioned in the prior section for desktops, the same methodology applies. All anti-virus or hardware antivirus packages must be implemented onto said server before let out onto the network. The Go Live process should cover such a build methodology. All antivirus packages should be standardized across the servers and tweaked according to the needs. All deployed servers must report back to a central hub for maintenance purposes from an experienced technician in order to actively monitor the current state of each server. (Tipton 2010)

 

Email servers should be given an extra layer of protection in regards to spam, viruses, etc. This should be done by implementing a blacklist filter prior to receiving email on the SMTP server.

1.1.3 Remote Access

Remote access should only be given to privileged users that are approved by a high authority. Such privilege should be noted in a database in order to accurately grant appropriate access to said user. All activity for users who are connecting remotely should be logged and audited for malicious or unintentional behavior found on the network. As mentioned before, appropriate anti-malware/virus software, client-based firewalls, approved devices should meet criteria prior to allowing remote connectivity onto the network. All traffic activity should be actively logged, monitored, and controlled by a central authority. All traffic within The Company Inc. will be considered medium to high impact on the systems, considering the information that is actively passed throughout the internal network. Therefore, an automated service must be implemented in order to monitor and control access of all remotely connecting users and to facilitate an appropriate, safe networking environment. (Tipton 2010)

 

All forms of remote access to the network must meet encryption standards and multifactor authentication methods (tokens, etc.). All VPN traffic must be IPSEC. As an administrator, for example, if one wishes to maintain a server remotely, a VPN connection must be established prior to connecting via SSH to handle the task. (Tipton 2010)

 

All VPN servers must be regulated by a frequent audit to determine appropriate patches, maintain the access list, etc. To perform such a function, this may only be performed from within the network, not remotely. (Tipton 2010)

1.1.4 Segmentation

All extranets must be segmented appropriately. Only specific traffic should be allowed in/out of the network within said extranet and routed appropriately (given the firewall rules, this may vary, as noted in the previous section on firewalls). All segmentation will be handled by the firewall rules that are determined for each zone. (Tipton 2010)

 

On each segment, Intrusion-Detection Systems must be in place and frequently audited (see IDS section). This is imperative to limiting breaches on the network, given the Internet-facing services that have been placed internally with The Company Inc.

 

All extranets should be appropriately separated, with access to only what is absolutely needed for said resource. (Tipton 2010)

1.1.5 Intrusion-Detection System (IDS)

All Internet-accessible and Internet access points must have an Intrusion-Detection System in place that is actively monitored, controlled, and audited on a frequent basis in order to mitigate threats. Upon improper functionality of an IDS, all network activity must cease. All implemented IDSs must be implemented within the network in The Company Inc. (Tipton 2010)

 

Network (NIDS) and Host-based (HIDS) IDSs must be implemented prior to allowing network traffic throughout the internal network. As mentioned in the previous section on segmentation, all access to resources must be limited; this is done so by selectively configuring each IDS appropriately, given its place on the network, and having access to a complete ACL. HIDS should maintain a proper set of definitions and should also be controlled by a central location within the company. (Tipton 2010)

1.1.6 Wireless

All wireless access points should be logged, monitored, and controlled from a central location by an appropriate high official. Upon implementation of a Wireless Access Point (WAP), the following must be executed before allowed usage may begin. All default SSIDs must be changed to something unique, all SSIDs may not be broadcasted, encryption of all traffic must be turned-on as WPA2, to connect to a WAP, a VPN connection must be established upon successful connection to a WAP signal (the network is considered to be untrusted, that is why a VPN connection must be established prior to transmission of data), and all authorized personnel to connect to the network must apply through the IT department to human resources in order to be granted access (MAC address filtering). (Tipton 2010)

1.2 Authentication

1.2.1 Administrative, Internal, and Remote Access Users

All activity within The Company Inc. is considered to be at least moderate and high-impact to the company. All said accounts must therefore use multifactor authentication (given the resource, this may vary). Appropriate Human Resources management must be in place in order to appropriately determine who has access to what within the network, along with friendly and unfriendly termination policies, etc. No form of authentication will be performed on a plain-text protocol. (Tipton 2010)

 

Administrative Users: Passwords must be changed every 90 days, must be alphanumeric, must contain upper and lowercase characters, at least one special character, with a minimum length of 14 characters. Every authentication attempt (be it successful/unsuccessful) will be logged and audited on a frequent basis. Accounts will be automatically locked-out upon 7 consecutive failed login attempts. Administrative accounts that require access to different resources in different departments will require multiple accounts. (Tipton 2010)

 

Internal Users: Passwords must be changed every 90 days, must be alphanumeric, must contain upper and lowercase characters, at least one special character, with a minimum length of 8 characters. Accounts will be automatically locked-out upon 7 consecutive failed login attempts. A regular training session must be implemented for new and current internal users to notify them of the dangers of password sharing. (Tipton 2010)

 

Remote-Access Users: Passwords must be changed every 90 days, must be alphanumeric, must contain upper and lowercase characters, at least one special character, with a minimum length of 8 characters. Accounts will be automatically locked-out upon 7 consecutive failed login attempts. Special restrictions apply to remote-access users, as mentioned in the previous sections (authentication, encryption, device standards, etc.). A regular training session must be implemented for new and current internal users to notify them of the dangers of password sharing. (Tipton 2010)

1.2.2 Password Policies (Administrators, Users, and Remote-Access Accounts)

All accounts will be logged, monitored, and controlled from a central location on a regular basis for suspicious activity by a high authority.

 

Administrators: See section above on password policies. As per account lockout because of 7 failed login attempts, network access must be limited at a minimum. Contacting the appropriate higher official will lift such a ban of the administrator account on the network. (Tipton 2010)

 

Users: See section above on password policies. As per account lockout because of 7 failed login attempts, network access must be limited at a minimum. After 5 minutes will the account be unbanned from the network. (Tipton 2010)

 

Remote-Access Accounts: See section above on password policies. As per account lockout because of 7 failed login attempts, network access must be limited at a minimum. Contacting the appropriate higher official will lift such a ban of the administrator account on the network. (Tipton 2010)

1.2.3 Inactive Accounts

As for all accounts (as mentioned earlier), they will be monitored and audited on a regular basis not only for suspicious activity, but for activity/if still owned by an active employee of The Company Inc. If proper deleting or locking of accounts (based upon friendly or unfriendly termination) has yet to be established based upon the policy, said account will be locked and audited. Upon termination of an employee, all administrators who monitor such events should be notified immediately. (Tipton 2010)

1.3 Management and Monitoring

1.3.1 Incident Reporting and Response

A central department should be in control of monitoring and reporting incidents to the appropriate levels of authority, be it internal administrators or the appropriate government authorities (upon breaches, etc.). Policies for hardening workstations and servers must be in place to help monitor appropriate patching, disable of services that are unneeded, etc. to be present. (Tipton 2010)

 

Upon recovering from an incident, prior to such a situation occurring, all servers should undergo a regular image backup and follow a typical disaster recovery document. Each workstation or server should have the latest patches, etc. while in the live state. (Tipton 2010)

 

Continue to monitor information from IDSs, network devices, firewalls, routers, etc. in order to appropriately respond to each incident.

 

Appropriate steps to maintaining incidents should be documented prior to any sort of server/workstation implementation.

1.3.2 Secure Build

The following has been mentioned in the aforementioned sections, and should be recognized as a summation of such: regular auditing of firewalls, patch all systems within the company, ensure that all connected devices have been approved, require consolidation of remote-access protocols into one accepted system of choice, all mobile devices that contain company data (such as laptops) should be encrypted with the company standard (e.g. DES), upon each build of a workstation, certain services should be disabled (such as remote control, etc.), disable modems on each laptop or desktop, and enforce passwords for screensavers. (Tipton 2010)

1.3.3 Physical Security

All access to IT related equipment should be locked and in a location that is out of sight of a regular employee. All access may be granted by multi-authentication, such as a badge, a fingerprint, and a password upon entering the secured area. All access must be logged prior to entering said area. All employees who are granted such access must be escorted by an authorized official. In regards to visitors, this applies as well, along with visitor badges provided to individuals (requires a proper picture form of identification, and an employee who may grant such access to the facility). (Tipton 2010)

 

An alarm system that is implemented in the company should be regularly tested. All file cabinets and other regular physical objects that contain sensitive data (such as printers and the like) should be locked. Documents that contain HIPAA information or any other sensitive data must be shredded after use and should never be left unattended. (Tipton 2010)

2. Applications

2.1 Deployment and Use

2.1.1 Load Balancing

Load balancing in an important part of ensuring even workload across the companies servers, and plays an integral role in ensuring reliability through redundancy. However having load balancing capabilities is not the end all solution. It is important to make sure the load-balancers are working properly by performing periodic audits, reviews, and tests. Especially with the use of internet applications, being able to ensure the load-balancers can handle traffic up to certain known break points is important. (Tipton 2010)

2.1.2 Clustering

Clustering is an important factor in high availability enterprise services. Designing an application infrastructure that can host multiple applications through interconnected servers is called clustering. by doing this you can get rid of possible bottle necks, increasing speed and also support increased availability by providing failover servers to take the load and hence continue running the application. With this, there also needs to be formalized testing of the failover mechanisms to ensure proper operation. (Microsoft)

2.1.3 Application and Data Recovery

For an organization that relies on IT to run its operations in different lines of business it is essential that there be some form of application and data recovery system in place. Utilizing an offsite storage, the databases should be mirrored with a minimum distance between data centers set at 100 miles. By having this site it will ensure continuity of business operations if a disaster should ever strike, i.e. tornado, fire, hurricane, etc. If data and application backup measures were not in place and a disaster were to strike, the company could risk losing valuable functions and information that could result in loss of business, law suits for not meeting production marks, and even closing of operations. (Microsoft)

2.1.4 Third Party Independent Software Vendor

Having third party vendors develop and support software has become an integral part of any organization with developed IT systems. Managing these vendors and making sure that the proper security measures are in place in order to mitigate risks is an important part of keeping the organizations systems healthy. In order to successfully do this there should be a formalized vendor relationship management process in place with regular reporting on function and security updates. Any patches that the vendor issues should be prioritized to be tested and implemented immediately to keep systems up to date.

 

Also, with key business functions relying on systems provided by third party vendors it essential to formalize communication. For this a vendor management office should be established in order to take ownership of the vendor relationship management process. Some of the tasks this office will carry out will start with gathering more information from the vendors using the BITS framework and the Standardized Information Gathering Questionnaire. This will help the team further review risks and take corrective action to mitigate where possible. (Microsoft)

2.1.5 Internally Developed

Working effectively with an in house development team to support applications is essential to keeping security up to date and strong. When patches are made available, it is the responsibility of the in house team to test these patches in a test environment. Also the in house team should be in charge of testing and auditing systems regularly. In addition a formal incident response plan should be in place to respond to issues that may arise both with internal and external facing applications. (Tipton 2010)

2.1.6 Vulnerabilities

Regular vulnerability assessments should take place to outline known vulnerabilities, prioritize, and set acceptable levels of risk. All known patches that are issued or developed for applications, must first be tested in a test environment to identify any unknown or negative interactions. There should be a formalized procedure in place to test all patches and this procedure should be revisited at least twice a year to make sure it is up to date with current applications.

Additionally third party internal auditors should be brought in once a year to assess the systems and their current vulnerabilities. Penetration tests should be conducted regularly to help identify vulnerabilities and help strengthen security. (Microsoft)

2.2 Application Design

2.2.1 Authenticity

Applications that use password to authenticate should be required to include complexities including minimum character length, mixed cases, dictionary checking, mixed characters (alpha, numeric, symbols) etc. For high level account such as administrative or root accounts, multi factor authentication should be applied. For all accounts there should be measures applied such as minimum number of failed attempts before getting locked out of the systems, and password expiration after a certain period of time. For remote logging, Kerberos authentication should be used. Record all attempted logs into accounts, and review periodically to determine any irregularities.

2.2.2 Password Policies

Passwords are the basis for system log in and need to be protected using some industry best practices. As such they must be treated with very strict policies. A password should never be written down a piece of paper and store somewhere other than a locker. No two people in an organization should have the same password. Do not save passwords anywhere on the computer. The password must be at least 7 digits long, and cannot use any dictionary words or users name. The password must be significantly different from any previous passwords. The password must contain numbers, letters, both upper and lower case and symbols. Passwords expire after 90 days and new ones must be chosen. (Tipton 2010)

2.2.3 Authorization and Access Control

Role based access control should be implemented at both the application and database level. The use of a security kernel reference monitor should be implemented allowing both discretionary access control and mandatory access control. The rules of access should be determined by the business side and the system should enforce it. Regular testing of key applications should be enforced; this testing should include penetration tests or "ethical hacking". The tests should cover a broad range of vulnerabilities and threats but should specifically test the ability of hackers to gain access into systems and elevate authorization privileges. (Tipton 2010)

2.2.4 Logging

Events should be logged and kept in secure databases with backup copies made for time periods specified by corporate policies. All attempts to log in to systems whether successful or failed should be logged. The failed attempts should be logged in order to track possible cracking attempts and the successful attempts should be logged to track user log in and activity. All access denies should be logged as well as any successful attempt to access private resources. In addition any changed to user accounts or data should be logged as well. These logs may come in useful in legal settings so it’s important to keep the integrity of these logs. (Tipton 2010)

2.2.5 Input Validation

Audit the applications on a regular basis to ensure that their inputs are valid and consistent. To do this it is important to revisit integrity constraints to ensure that they are in line with specific output needs of the organization. Beware of vulnerabilities and threats such as buffer overflow attacks and attempt to reverse engineer the threats to mitigate risks of them occurring. (Tipton 2010)

2.2.6 Software Security Development Methodologies

Utilize software development life cycle for all development projects. The following baseline stages should be adhered to: Requirements, design, implementation, verification, release, support and servicing. Within these sections there should be more specific details outlined such as code sign off, testing in secure environment, etc. The main factor is make the process easy to follow and repeatable. All security engineers need to be trained in all factors that affect your particular organizations i.e. what assets are you protecting, through what means are you protecting them, current security architecture and standardized security development methodologies.

2.3 Data Storage and Communication

2.3.1 Encryption

All data will be labeled according to their description and classification. It is important for applications to be able to distinguish between what needs to be hashed permanently, such as passwords or things that should be encrypted strictly for communication purposes. The data that should be encrypted for communication purposes should use a hybrid encryption model. This model combines the strengths of speed with symmetric encryption with the security of asymmetric encryption. In addition it makes key management a lot easier as with strictly symmetric encryption there needs to be a one to one relationship between each and every machine/person who communicates. (Tipton 2010):

2.3.2 Encryption – Algorithm

Do not use key size smaller than 128 bits. Right now the organization is using AES4/Rijandel encryption and this should continue to be used. The hashing algorithm being used is SHA-1, but it presents a number of vulnerabilities. Currently, there are no better alternatives but when one is developed it is important to stay up to date and take advantage of that opportunity. (Microsoft)

3. Operations

3.1 Environment

3.1.1 Management Host

Any remote management of servers, clients, or network devices should be conducted over a secure connection (e.g. SSL or IPSec VPN).

3.2 Security Policy

3.2.1 Data Classification

All information stored by the company should be classified based on the impact of unintentional disclosure. Three classifications are defined below (Microsoft):

§  High Business Impact (HBI): assets that, if lost, could cause severe material loss to the company, asset owner, or related third parties.

§  Medium Business Impact (MBI): assets that, if lost, could cause material loss to the company, asset owner, or related third parties.

§  Low Business Impact (LBI): assets that, if lost, would cause little or no material loss to the company or the asset owner.

 

Limit access to HBI and MBI information to people with a legitimate business reason for access (Microsoft).

3.2.2 Data Disposal

Improper disposal of media containing company information could lead to unintentional or unauthorized disclosure. The appropriate method for disposing of media is based on its classification (see section 3.2.1) (Microsoft):

High Business Impact:

§  Cross-shred paper documents in locked shred containers.

§  Destroy all electronic storage media that is old, inoperable, or being replaced (hard drives, CDs / DVDs, flash drives, tapes).

 

Medium Business Impact:

§  Cross-shred paper documents in locked shred containers.

§  Overwrite data on hard drives that are to be reused.

Destroy other electronic storage media that is old, inoperable, or being replaced (CDs / DVDs, flash drives, tapes).

 

Low Business Impact:

§  No specific disposal requirements.

 

All destruction activity should be logged and any corresponding asset records should be updated (Microsoft).

3.2.3 Acceptable Use

Use of any resources owned or controlled by the company is limited to business purposes only. Personal use, or any other use not connected with the company's business activities, is not permitted (Tipton 2010).

3.2.4 User Account Management

User accounts should be created and updated in a controlled fashion to protect the confidentiality and integrity of the company’s information assets. The people and processes responsible for managing accounts should be carefully supervised to ensure accountability. Following these best practices for managing user accounts will help control the operations for managing user access (Tipton 2010):

§  Adhere to the principle of least privilege by granting users the minimum level of system access required to do their jobs.

§  Review privileged accounts regularly to ensure that a continuing business need exists. Disable accounts that are no longer needed.

§  Review all accounts regularly to find dormant accounts. Accounts belonging to employees or contractors that have left the company or are on leave should be disabled.

§  Minimize shared use of shared administrative accounts (i.e. root) to prevent loss of accountability. Log all use of these accounts.

§  Enforce separation of duties limiting user access to only specific activities within key business processes. Maintaining separate access rights across a business process prevents errors and fraud by requiring multiple users to complete the work.

§  Use tools that allow users accounts to be managed using groups and roles as opposed to assigning unique levels of access for each individual.

3.2.5 Governance

Ensure that the appropriate policies, processes, people, and technologies are in place to support the company's goals by maintaining an information security management function within the company. The security professionals within this function will be responsible for maintaining confidentiality, integrity, and availability of the company's information and for informing managers of possible risks so that they can make informed decisions (Tipton 2010).

 

3.2.6 Security Policies

A complete set of formally established policies is necessary for communicating the company's expectations, goals, and objectives. Develop, document, and disseminate information security policies and support policy implementation by including additional components that support the policies (Tipton 2010):

§  Standards: specific hardware and software requirements for compliance with policy

§  Procedures: detailed instructions for completing tasks in compliance with policies and standards

§  Baselines: best practices for configuring hardware and software components in compliance with policies and standards

§  Guidelines: discretionary recommendations for complying with a policy, standard, or baseline

 

Policies should be reviewed every two years to ensure they stay relevant and address any new issues or technologies. Using a formal process for creating and updating policies in which all business functions are involved will ensure that all business issues are considered. Getting executives to oversee the policy management process and endorse the policies will ensure that all levels and functions within the company accept them. (Tipton 2010)

 

Employees must be aware of the policies for them to be effective. All policy documents should readily available by including them in the employee handbook and posting them on the intranet. While this will not guarantee that policies have been read, obtaining signatures from all employees that they acknowledge the policies will help protect the company from legal action should an employee violate the policy. Distributing the documentation only goes so far. By educate employees through a security awareness training program, the company can increase compliance by explaining to employees why the policies exist, what their responsibilities are, and the sanctions for noncompliance. (Tipton 2010)

 

Finally, any employee who violates the policy needs to be sanctioned in order for the company to meet its objectives and to maintain an effective control environment. (Tipton 2010)

3.3 Patch and Update Management

3.3.1 Network Documentation

An enterprise network cannot be managed if documentation does not exist regarding the devices, protocols, locations, and addresses used. Detailed documents and schematics should be maintained and updated as new devices are added or as connectivity changes. (Tipton 2010)

 

3.3.2 Application Data Flow

Developers, system architects, data custodians, system administrators, and business users need an accurate, authoritative reference on the flow of information between applications and data stores. Document the flow of data from throughout the organization to identify where data is stored (e.g. databases) and which applications rely on which data. This documentation should identify the source, dependencies, format, and owner of the data. Update this documentation as data stores and applications are modified, added, or retired. (Tipton 2010)

3.3.3 Patch Management

Employ a formal process for applying patches and system updates. Patches and updates are issued regularly, and each one will go through a formal patch management process before it is deployed on a production system. (Tipton 2010)

 

A patch management process should include each of the following steps (Tipton 2010):

1.      Determine whether patch is required based on the probability of the vulnerability being exploited and the impact of an exploit.

2.      Test the impact of applying the patch and determine if any other actions are necessary to maintain a functional system.

3.      Plan deployment and notify users.

4.      Backup system in case patch causes an unexpected failure.

5.      Deploy patch into production.

6.      Validate that the patch is effective and that the system is functional.

7.      Document changes.

 

Vendors will be a primary source of information on available patches, but third-party sources should also be monitored for information on vulnerabilities that have been identified. Examples of third-party sources (Tipton 2010):

§  cve.mitre.org

§  nvd.nist.gov

§  cert.gov

 

Be proactive in identifying system vulnerabilities by conducting periodic vulnerability testing to identify systems that require updates or need mitigating controls to be applied (Tipton 2010).

3.3.4 Change Management and Configuration

3.3.4.1 Change Management

Ensure that any changes to the company’s information systems support business goals and manage risk by following a formal change control process (Tipton 2010).

 

A change control process should include each of the following steps (Tipton 2010):

1.      Formal change requests that include a business case are submitted to the committee in writing.

2.      An assessment is conducted to determine the operational impact of the change.

3.      The change committee makes a decision to accept or reject the request.

4.      The change is built, implemented, and tested in a non-production environment.

5.      Users are notified of the change and deployment schedule.

6.      The change is deployed into the production environment and validated.

7.      Documentation is updated to reflect the change.

 

 

Establish a committee of representatives from across the business to evaluate and authorize changes. The committee should include upper-level managers, end-users, security personnel, developers, operators, and administrators to ensure that all perspectives and potential issues are considered. (Tipton 2010)

3.3.4.2 Configuration Management

Maintain detailed inventories of all hardware used within the organization. By having an accurate list of all equipment, it can be replaced in the event of failure or loss. It also enables the organization to identify affected machines if a vulnerability becomes known. And, it can be used when scanning the network to identify unauthorized hardware. (Tipton 2010)

 

At a minimum, store the following information (Tipton 2010):

§  Manufacturer

§  Model

§  MAC address

§  Serial number

§  Software version

§  Location

§  Passwords

§  Assigned IP address

§  Asset tag ID

 

Keep records of configuration settings for all workstations, servers, and networking equipment to maintain integrity and to facilitate quick recovery if a device should become inoperable.

 

Update configuration records whenever a change is made due to an update or when a new system is added or an old one retired. Configuration records are HBI information, so the appropriate level of security should be applied to their storage to prevent corruption or disclosure. (Tipton 2010)

3.4 Backup and Recovery

3.4.1 Log Files

System log files enable operators, administrators, technicians, and auditors to audit, monitor, and troubleshoot information systems. Log files contain detailed information on system configuration and activities, which could be useful to an attacker. So, all log files should be treated as HBI information. In analyzing log files, it is easy to modify their contents. So, to preserve their integrity, users should make working copies of the files rather than working from the original file itself. Also, log files can easily grow to occupy large amounts of storage, so administrators and managers should determine the appropriate period of time for system logs to be kept (e.g. if there are any applicable regulatory requirements) and delete old logs when no longer needed. Also, administrators should review system log files daily to understand typical system activity so that when they need to be analyzed, the irregular activity can be more easily identified. Finally, log management tools and processes should be reviewed periodically and any updates required to continue effective logging should be made (Kent and Souppaya).

3.4.2 Disaster Recovery Planning and Business Continuity Planning

Emergencies such as fire, flood, tornado, terrorist attack, or utility outage pose a threat to the availability of the company’s information systems and business processes. Plans for continuing critical business operations in the event of these disruptions should be created, maintained, tested and documented to prevent financial, legal, or reputational risk to the company. A business continuity and disaster recovery process should include, at a minimum, consider of the following (Tipton 2010):

§  Perform a risk analysis and a business impact analysis to determine the biggest threats and most time-sensitive business functions in order to prioritize planning efforts.

§  Conduct an annual test of all plans to allow employees time to practice and to identify any areas where plans may need to be improved.

§  Reflect any changes to organization or to the system landscape in the plan documents as they occur to ensure that plans remain current.

§  Administer a training program annually for the entire organization to build awareness of the importance of the plan and their responsibilities for ensuring its successful execution. Post information on the company intranet containing procedures and contact information so that it can be easily referenced if needed.

§  Establish a physical and virtual Emergency Operations Center for conducting the response and recovery activities and for sharing information.

3.4.3 Backup and Restore

3.4.3.1 Backup

Errors occur, hardware fails, disasters happen, and users make mistakes, so current copies of user and system data should be maintained so that systems can be quickly and completely restored. To ensure adequate protection against loss, create three separate copies of backup data: one on-site to restore failed systems, one at a nearby facility in case the primary facility is damaged, and one in a different geographic location in case of a catastrophe. Regardless of the facility, any media containing backup data should be stored in a properly secured location to prevent theft, tampering, or damage. Maintaining excess backups can complicate management, so periodic review should be conducted of backups in storage to ensure that data is not kept for longer than required.

Also, backup systems and procedures should be regularly tested to ensure that they are reliable and effective (United States Department of Energy). Finally, records should be kept of the data being stored in each location. (Tipton 2010)

3.4.3.1 Restore

Restoring systems or data from backups may happen only infrequently, so it is important to have clear, well-defined systems and processes (United States Department of Energy). Test restoration systems and processes periodically to ensure that systems can be restored quickly and completely when required and to ensure that personnel are familiar with the procedures. (Tipton 2010)

4. People

4.1 Requirements and Assessments

4.1.1 Security Requirements

All individuals who are educated on the materials/consist of the level of duty in regards to security as well as the necessary employees within the business realm will either be briefed or involved during any such decisions that revolve changes to security policy or what have you. As per hardware within the environment, all components within the organization (be it servers, networking devices, etc.) will be appropriately assigned a level of criticality: low, medium, high. All of such labeling is a part of the Go Live process for any new introduction of network or server equipment. Upon issues that arise with such devices, the appropriate authorities within the company will be notified immediately for repair/replacement.

4.1.2 Security Assessments

All audits of the security infrastructure (network and applications) must be performed on a quarterly basis by an internal audit team, as well as a third-party vendor (by alternating between each of these groups) that is capable of handling such a situation.

 

To better improve the company, one must include their findings from the results of the assessments into ongoing projects with the company. This will give better transparency to the company goals so that all functions within the business are aware of what to expect, and allows them to make suggestions for further improvements.

4.2 Policy and Procedures

4.2.1 Background Checks

Individual employees responsible for managing information security could pose a significant legal, financial, or reputational risk to the company if they were to lie or misrepresent themselves during the hiring process or their term of employment. On prospective employees, the company should conduct a background investigation that includes, at a minimum, the following areas (Tipton 2010):

§  Reference checks

§  Criminal history

§  Credit history

§  Employment history

§  Educational records

§  Status of certifications held

§  Drug test

 

All applicants for positions that are responsible for managing technology (e.g. IT or information security departments) or confidential information (e.g. research and development department) must undergo the screening process, so the entire organization - from the hiring manager to the human resources department and recruiters - must understand the process. (Tipton 2010)

4.2.2 Human Resources Policy

4.2.2.1 Job Descriptions

In order to attract suitable candidates for open positions, accurate descriptions of the responsibilities and skills required for each job should be maintained. Having current job descriptions can also help current employees identify future positions they may like to apply for. Managers can also use these as a tool for succession planning and employee development conversations. (Tipton 2010)

 

Human resources should collaborate with functional managers to capture the details of each position. Before any open position is posted, the hiring manager is responsible for ensuring the accuracy of the job description and working with the HR manager to make any changes. As organizational roles evolve or as reorganizations occur, these descriptions should be updated through a collaborative effort between HR and each function. (Tipton 2010)

4.2.2.2 Employment Agreements

Employment agreements are important for the company and the employee to establish a common understanding of the rules and terms of employment, and to protect the company from potential legal action. Each employee that may come into contact with confidential or proprietary information is required to sign a non-disclosure agreement before beginning employment. Additionally, as part of their initial training, all employees will attend a course on ethics and the company's code of business conduct and sign an acknowledgement that they have received the training and agree to be bound by its terms. (Tipton 2010)

4.2.2.3 Employee Supervision

Monitoring employee performance allows the company to effectively manage employee performance and gives it a tool to take corrective action on any employee who is not meeting expectations. Each manager should conduct a complete performance review for each of his direct reports at the end of each fiscal year. Managers should also conduct informal quarterly reviews with their direct reports to offer suggestions for improvement and to develop any skills that may be lacking. (Tipton 2010)

4.2.2.4 Termination of Employment

In order to ensure ongoing confidentiality and integrity of the company's information, an orderly procedure for removing system access must exist. Depending on whether the termination is under friendly or unfriendly circumstances, this determines how best to handle removing access. For friendly terminations, all physical items (e.g. ID badges, keys, tokens) should be collected at the exit interview and all system access should be removed on the employee's last day. In the event of an unfriendly termination, system access should be removed before the employee is notified to prevent retaliation. (Tipton 2010)

4.2.3 Third Party Awareness

Security expectations should be clearly defined in any contracts or agreements with third-party service providers. Specific metrics, such as service level, should be used to evaluate the provider on an ongoing basis. Also, any provider that is storing or processing company data off-site must have a SAS-70 certification. (Microsoft)

4.3 Training and Awareness

4.3.1 Security Awareness

Knowledge employees are the best employees. Develop a security awareness program that effectively aligns channels of communication with all stakeholders. It is important to have the ability to notify employees of security alerts that keeps them in the loop in real time. Also it is important to have all employees understand the importance of security in real business terms so it is not just an abstract concept. From this they may be more cognizant of security issues in their everyday work. Basic security training should be provided to all employees on a quarterly.

4.3.2 Security Training

Role based training is important and continuing education is important staying up to date with current security issues. Teams should be formed to consult with the business side to determine the most critical issues facing them and acceptable down times of critical issues on an on-going basis. Security personnel should be held to yearly classes to update them on new issues. They should also be required to get specific security certifications as deemed necessary.


 

References

Brunette, Glenn. "Adaptive Security and Security Architecture." New Directions in Security.  N.p., 6 Aug 2008. Web. 11 Dec 2010. <http://blogs.sun.com/adaptive_security/entry/adaptive_security_and_security_architecture>.

Brunette, Glenn. "Adaptive Security Architecture Principles." New Directions in Security.  N.p., 5 Sep 2008. Web. 11 Dec 2010. <http://blogs.sun.com/adaptive_security/entry/adaptive_security_architecture_principles>.

Kent, Karen and Souppaya, Murugiah. "Guide to Computer Security Log Management." Recommendations of the National Institute of Standards and Technology Sep 2006: 5-11 - 5-12. Web. <http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf>.

Microsoft Corporation. "Securing Business Information." Microsoft IT Showcase 18 Jan 2010: 1-9. Web. <http://technet.microsoft.com/en-us/library/bb687781.aspx>.

Microsoft Corporation. "Microsoft Security Assessment Tool 4.0." Microsoft Corporation. N.p., 9 Oct. 2009. Web. 11 Dec. 2010. <http://www.microsoft.com/downloads/en/details.aspx?FamilyId=CD057D9D-86B9-4E35-9733-7ACB0B2A3CA1&displaylang=en>.

Tipton, Harold. Official (ISC)2 Guide to the CISSP CBK. Second ed. Boca Raton, FL: CRC Press, 2010. Print.

United States Department of Energy. "IT Security Architecture." U.S. Department of Energy Enterprise Architecture Feb 2007: 1-52.

Weise, Joel. "Designing and Adaptive Security Architecture." Sun Microsystems 3 Nov 2008: 1-16.