A few weeks ago, Deloitte Touche Tohmatsu (DTT) released the results of its Annual Global Security Survey for 2008. The survey focuses on the information security needs, practices and priorities of the financial industry, which is among the most regulated of all vertical markets. Not surprisingly, the top priority for the security officers interviewed was “security regulatory compliance.” What is a bit surprising was that security compliance took the top spot for the first time, followed by “regulating access control”, which was the number one priority in 2007.
The report provides a number of interesting details, many of them pointing to continued problem of the “human factor” in security. According to the survey, the number one root cause of all security incidents experienced at these organizations was “human error.” (This is not a surprise, as nearly all data breach and incident studies come to a similar conclusion.) What IS surprising is that despite the concern about human error, the category for “security awareness and education” was 7th on the overall list of 15 priorities. While this tremendous gap between cause and prevention is indicated in this report, it is echoed throughout the industry. Everyone “gets it” that security is fundamentally a people problem, and yet when you look at spending and organizational priorities, education and awareness is near the middle or bottom of the list.
When new technology is introduced into the mix, the potential knowledge gap widens as technology makes into production before the much-needed awareness and policy guidance. In fact, the report revealed a fairly large gap between the deployment of new technology and the issuing of specific policies and guidance on the safe use of the technology.
One prime example is mobile security. According to the survey, very few organizations (less that 10%) actually prohibit the use of mobile storage (USB drives, Media Players, etc.) because of fears that this will limit productivity. In other words, 90% of organizations are using mobile storage in the enterprise. Yet only 40% of these same organizations publish policies and procedures on acceptable use of mobile storage. The statistics are similar for mobile computing technology (handheld computers, PDA, etc.). Only 27% limit these devices, and yet only 42% claim to have issued acceptable use policies.
Given the facts that human error is the root cause of most security incidents, the “knowledge gap” created when organizations permit technology without written acceptable use policies represents a significant risk. Written security policies are the official “contract” between management and employees on the appropriate use and misuse of new technology. And while polices do not replace awareness and training, they significantly enhance these efforts by forcing management to think through the various risks and trade-offs of adopting new technology.
If your organization is searching for cost-effective ways to keep policies updated based on the latest technologies, we encourage you to evaluate our PolicyShield Security Policy Subscription. We believe written policies are key for enabling safe, yet productive use of new technology.
Monday, April 27, 2009
Tuesday, February 17, 2009
Ideas for Security Policy Sanctions
In order for written information security policies to have "teeth", there must be consequences for employees that do not follow policies, and this fact must be documented as part of the published policy. The "sanctions" portion of most security policies reads something like this:
"Failure to comply with this policy will result in disciplinary action, up to and including termination."
While this idea certainly makes sense as a formal statement, it leaves a lot of gray area in the real world of policy implementation and enforcement. And it will likely leave questions in the minds of employees. "Does this mean that everyone who violates a policy gets fired?" "What happens if I violate a policy by accident?" "What offenses would warrant termination?"
When developing written policies, the organization should prepare some internal guidelines for proper sanctions. These should be developed in conjunction with Human Resources and the Legal Department, and considered with regard to consequences for violation of other policies such as Code of Conduct. Certainly, all policy violations are not the same, and some violations present greater legal and market risk that others.
The following are some ideas for possible employee sanctions with increasing levels of severity:
1. Warning from Management -The employee receives a warning from their manager that they were in violation of policy.
2. Official Warning in Personnel File - The employee is warned, and official notice is put in their personnel file. This may have negative consequences during future performance reviews or promotion considerations.
3. Revoking Privileges - Access to certain company resources, such as internet or email, can be revoked for a limited period. (Providing that they are not critical to job functions.) In one organization, the CEO gave everyone in the organization 30 days to read and acknowledge the written security policy. After 30 days, each employee had their email disabled. Within 24 hours all of the offenders had read and acknowledged the policy.
4. Requiring Additional Training - Another sanction is to require the employee to take additional training on security and privacy practices. This must be done on their own personal time, such as during lunch or after business hours.
5. Suspension without Pay - After multiple warnings, or for serious policy violations that may put the company at substantial risk, employees may be suspended for a limited time without pay.
6. Termination - The organization should consider which types of offenses could trigger a termination. If termination is an option, consult with the legal and human resources department to make sure the organization is on solid ground with respect to written policies. Some employees have sued for wrongful termination and won the case when it was shown that the company was lax in its overall deployment and enforcement of security policies.
Of course, you can combine any of these into a type of sanctions "mix" that works for the organization. The important task is to prepare the organization by thinking through the problem and deciding what works best for the employees and management. Once guidelines have been established, they can be communicated to employees as part of their regular security or human resources training activities.
If your organization has come up with some unique and effective ways to encourage compliance with policies, we would like to hear from you.
"Failure to comply with this policy will result in disciplinary action, up to and including termination."
While this idea certainly makes sense as a formal statement, it leaves a lot of gray area in the real world of policy implementation and enforcement. And it will likely leave questions in the minds of employees. "Does this mean that everyone who violates a policy gets fired?" "What happens if I violate a policy by accident?" "What offenses would warrant termination?"
When developing written policies, the organization should prepare some internal guidelines for proper sanctions. These should be developed in conjunction with Human Resources and the Legal Department, and considered with regard to consequences for violation of other policies such as Code of Conduct. Certainly, all policy violations are not the same, and some violations present greater legal and market risk that others.
The following are some ideas for possible employee sanctions with increasing levels of severity:
1. Warning from Management -The employee receives a warning from their manager that they were in violation of policy.
2. Official Warning in Personnel File - The employee is warned, and official notice is put in their personnel file. This may have negative consequences during future performance reviews or promotion considerations.
3. Revoking Privileges - Access to certain company resources, such as internet or email, can be revoked for a limited period. (Providing that they are not critical to job functions.) In one organization, the CEO gave everyone in the organization 30 days to read and acknowledge the written security policy. After 30 days, each employee had their email disabled. Within 24 hours all of the offenders had read and acknowledged the policy.
4. Requiring Additional Training - Another sanction is to require the employee to take additional training on security and privacy practices. This must be done on their own personal time, such as during lunch or after business hours.
5. Suspension without Pay - After multiple warnings, or for serious policy violations that may put the company at substantial risk, employees may be suspended for a limited time without pay.
6. Termination - The organization should consider which types of offenses could trigger a termination. If termination is an option, consult with the legal and human resources department to make sure the organization is on solid ground with respect to written policies. Some employees have sued for wrongful termination and won the case when it was shown that the company was lax in its overall deployment and enforcement of security policies.
Of course, you can combine any of these into a type of sanctions "mix" that works for the organization. The important task is to prepare the organization by thinking through the problem and deciding what works best for the employees and management. Once guidelines have been established, they can be communicated to employees as part of their regular security or human resources training activities.
If your organization has come up with some unique and effective ways to encourage compliance with policies, we would like to hear from you.
Monday, January 26, 2009
Top Security Policy Priorities for 2009
A New Year is always a good time to reflect on the past and make plans for the future. 2008 was a very busy year for security breaches, with 656 reported breaches exposing up to 35 million customer records according to a recent report by the Identity Theft Resource Center (ITRC). This was nearly a 50% jump from 2007.
Since our focus is the development of information security policies, we decided to take a look back at 2008 and see if we could draw some conclusions about trends and priorities for 2009. Think of this as an industry-wide risk assessment exercise. Based on some of the largest incidents of 2008, which information security and data privacy policies, if properly implemented, would have helped reduce the likelihood or impact of these incidents? (Needless to say, many of these policies are contained within Information Security Policies Made Easy.)
The stakes are getting higher. According to a study conducted by the Ponemon Institute, data breaches are costing businesses an average of $197 per customer record, up from $182 in 2006. So, based on some of the top incidents of 2008, here are our suggested top security policy priorities for 2009:
1. Data Breach Notification Policies
Despite the many costly, embarrassing data breaches that have been reported over the last several years, organizations seem to get caught without a plan for dealing with breaches that involve sensitive customer data. Slow or poorly organized responses end up creating confusion and increasing the potential damage of the breaches.
Six months after a breach happened at the parent company of the Montgomery Ward website, the company Direct Marketing Services finally began notifying customers that their credit card information was stolen in part of a hack that stole at least 51,000 records in December 2007. In March, the Maine-based Hannaford Brothers grocery store chain announced that 4.2 million customer card transactions had been compromised by hackers. More than 1800 credit card numbers were immediately used for fraudulent transactions.
A data breach notification policy must include a variety of possible elements, including breach reporting procedures, documentation of breach notification requirements (by state or country), notification methods and schedules, and the establishment of breach response teams. (See our free Privacy Breach Calculator from the Privacy Management Toolkit.)
Data breach response is going to end up on the radar sooner or later. The recent Homeland Security Agenda announced from President Obama includes a goal for a nationwide breach notification law, but so far no national law has been passed, leaving a patchwork of state-level requirements within the United States.
2. Tracking of Physical Media in Transit
Another common theme in many incidents is the loss of physical media, including laptops, PDAs, hard drives and backup tapes. Since the data is often not encrypted (See item #3), the loss triggers breach notification requirements (See item #1).
There are a variety of controls that can be addressed in policy, from the most basic (tracking the delivery of sensitive equipment) to the more complex (laptop tracking software, RFID tags). As always, employees play a key role since they are often the ones transporting the sensitive information. An effective Mobile Device security policy must cover the controls around the logical and physical protection of mobile devices.
The number of incidents involved lost media and mobile devices are too numerous to talk about in detail. (Several web sites do maintain such a list, including the Open Security Foundation (OSF) Loss Database and the Privacy Rights Clearinghouse. According to the Open Security Foundation, stolen laptops account for the largest share of data breaches, at 22% of the total.
3. Encryption of Sensitive Data Backups
This policy is really a subset of a wider set of controls involving the monitoring and tracking of sensitive customer data throughout its lifecycle. However, this one deserves special attention due to some large incidents in 2008.
In February 2008, an unencrypted backup tape with 4.5 million customers of the Bank of New York Mellon went missing after it was sent to a storage facility. The missing tape contains social security numbers and bank account information on 4.5 million customers - including several hundred thousand depositors and investors of People's United Bank of Connecticut. Early in January, Iron Mountain reported that it could not find a backup tape that belonged to GE Money, containing information on over 650,000 J.C. Penney customers and 100 other retailers.
Encryption policies involve a variety of control areas, including identifying the data that must be encrypted, choosing and implementing encryption methods, and encryption key management. (ISPME has over 50 security policies addressing this topic.) Many organizations that process sensitive customer data are finding it more cost effective to simply encrypt all data, rather than identifying the subsets required. Despite the obvious need for encryption, according to ITRC reports, only 2.4% of all breaches had encryption or other strong protection methods in use.
4. Malicious Software Prevention
Companies are increasingly falling prey to malicious software being installed and resident on their systems. Trojans and keystroke loggers were responsible for a number of high-profile breaches, including the Best Western Hotels, where thousands of user accounts were stolen and began appearing on Russian Mafia web sites within hours of the heist. In potentially one of the largest recent breaches, Heartland Data Systems has acknowledged a data security breach that may affect tens of millions of payment card accounts. Initial investigation revealed malicious software on their network.
In November, security vendor RSA said it found a single Trojan that had taken more than 500,000 online banking accounts credentials, credit cards and other resources. The reported indicated that the hacking gang behind the Trojan may have been operating for as long as three years. The compromised data came from hundreds of financial institutions around the world.
There are a number of related information security policies that can help address this common threat. These include standard security configurations for desktop and mobile devices, regular updates of virus and malicious software signatures, regular scanning of networked systems, and user education and awareness on software downloading and responding to phishing emails (see Item #5).
5. Employee Security - Screening, Education and Awareness
It is unlikely that there will be a year when employee education and awareness would not be a top information security priority. From rogue insiders going undetected to employees accidentally downloading spyware from a phishing attack, users are always at the front lines of many attacks. It has been said so many times that we can be numb from hearing it – educated users are essential to any security program. And yet, organizational priorities to not always follow this basic premise. A 2008 study by the Computer Security Institute showed that the average organization spends less than 1% of their budget on security awareness.
There are a number of security policies that can help integrate information security responsibilities into the workforce. Some examples include the requirements for annual security training, quarterly awareness activities, the formal documentation of information security responsibilities for various job roles, and validation of these in formal job reviews.
5.1 - The Insider Threat
This special area of employee-related security deserves special attention.
An alarming number of breaches now involve malicious employees or contractors. The breaches range from cases of espionage, to the simple pilfering of customer data for personal gain. According the ITRC report, insider theft - now at 15.7% of all breaches - has more than doubled between 2007 and 2008.
In one of the largest insider incidents of 2008, a former Countrywide Financial Corp. senior financial analyst was arrested and charged by the FBI for stealing and selling sensitive personal information of an estimated 2 million mortgage loan applicants. The data was taken over a two year period and sold to competitors. In March 2008, a former bank programmer at Compass Bank was charged after he had stolen a hard drive with 1 million customer records and used it to commit debit-card fraud.
A recent case involved a database administrator of a UK company, who was fined and sentenced to three months in jail after hacking into his former employer’s computer system. Later investigation revealed that the man had lied on his resume and also had prior criminal charges.
Written security policies can also help address the growing insider threat, and must focus on the entire lifecycle of employees and contractors. Examples include screening of employees in positions of trust, regular review of access rights, integration of security roles into job descriptions, monitoring of systems for unusually large transactions, and post-employment removal of logical and physical access rights.
Summary
So there are our top five categories. They are certainly not comprehensive, but they can give you a start on your priorities for 2009.
So what can we learn from this list? First, most data breaches involve a variety of factors, including both people and technology. So a variety of controls are required to help reduce the risk of these incidents. As we see from the analysis, most security policies are dependent on other policies to be completely effective. Privacy policies, encryption policies and backup policies must work together to prevent a breach involving stored sensitive data. User awareness and training policies must worth with malicious software detection and configuration control to help stop identity theft and the spread of botnets.
That is why Information Shield strives to provide the most comprehensive library of information security policies available. If your organization has gaps in any of these key areas, we encourage you to take a look at our security policy products. We look forward to serving you in 2009.
Since our focus is the development of information security policies, we decided to take a look back at 2008 and see if we could draw some conclusions about trends and priorities for 2009. Think of this as an industry-wide risk assessment exercise. Based on some of the largest incidents of 2008, which information security and data privacy policies, if properly implemented, would have helped reduce the likelihood or impact of these incidents? (Needless to say, many of these policies are contained within Information Security Policies Made Easy.)
The stakes are getting higher. According to a study conducted by the Ponemon Institute, data breaches are costing businesses an average of $197 per customer record, up from $182 in 2006. So, based on some of the top incidents of 2008, here are our suggested top security policy priorities for 2009:
1. Data Breach Notification Policies
Despite the many costly, embarrassing data breaches that have been reported over the last several years, organizations seem to get caught without a plan for dealing with breaches that involve sensitive customer data. Slow or poorly organized responses end up creating confusion and increasing the potential damage of the breaches.
Six months after a breach happened at the parent company of the Montgomery Ward website, the company Direct Marketing Services finally began notifying customers that their credit card information was stolen in part of a hack that stole at least 51,000 records in December 2007. In March, the Maine-based Hannaford Brothers grocery store chain announced that 4.2 million customer card transactions had been compromised by hackers. More than 1800 credit card numbers were immediately used for fraudulent transactions.
A data breach notification policy must include a variety of possible elements, including breach reporting procedures, documentation of breach notification requirements (by state or country), notification methods and schedules, and the establishment of breach response teams. (See our free Privacy Breach Calculator from the Privacy Management Toolkit.)
Data breach response is going to end up on the radar sooner or later. The recent Homeland Security Agenda announced from President Obama includes a goal for a nationwide breach notification law, but so far no national law has been passed, leaving a patchwork of state-level requirements within the United States.
2. Tracking of Physical Media in Transit
Another common theme in many incidents is the loss of physical media, including laptops, PDAs, hard drives and backup tapes. Since the data is often not encrypted (See item #3), the loss triggers breach notification requirements (See item #1).
There are a variety of controls that can be addressed in policy, from the most basic (tracking the delivery of sensitive equipment) to the more complex (laptop tracking software, RFID tags). As always, employees play a key role since they are often the ones transporting the sensitive information. An effective Mobile Device security policy must cover the controls around the logical and physical protection of mobile devices.
The number of incidents involved lost media and mobile devices are too numerous to talk about in detail. (Several web sites do maintain such a list, including the Open Security Foundation (OSF) Loss Database and the Privacy Rights Clearinghouse. According to the Open Security Foundation, stolen laptops account for the largest share of data breaches, at 22% of the total.
3. Encryption of Sensitive Data Backups
This policy is really a subset of a wider set of controls involving the monitoring and tracking of sensitive customer data throughout its lifecycle. However, this one deserves special attention due to some large incidents in 2008.
In February 2008, an unencrypted backup tape with 4.5 million customers of the Bank of New York Mellon went missing after it was sent to a storage facility. The missing tape contains social security numbers and bank account information on 4.5 million customers - including several hundred thousand depositors and investors of People's United Bank of Connecticut. Early in January, Iron Mountain reported that it could not find a backup tape that belonged to GE Money, containing information on over 650,000 J.C. Penney customers and 100 other retailers.
Encryption policies involve a variety of control areas, including identifying the data that must be encrypted, choosing and implementing encryption methods, and encryption key management. (ISPME has over 50 security policies addressing this topic.) Many organizations that process sensitive customer data are finding it more cost effective to simply encrypt all data, rather than identifying the subsets required. Despite the obvious need for encryption, according to ITRC reports, only 2.4% of all breaches had encryption or other strong protection methods in use.
4. Malicious Software Prevention
Companies are increasingly falling prey to malicious software being installed and resident on their systems. Trojans and keystroke loggers were responsible for a number of high-profile breaches, including the Best Western Hotels, where thousands of user accounts were stolen and began appearing on Russian Mafia web sites within hours of the heist. In potentially one of the largest recent breaches, Heartland Data Systems has acknowledged a data security breach that may affect tens of millions of payment card accounts. Initial investigation revealed malicious software on their network.
In November, security vendor RSA said it found a single Trojan that had taken more than 500,000 online banking accounts credentials, credit cards and other resources. The reported indicated that the hacking gang behind the Trojan may have been operating for as long as three years. The compromised data came from hundreds of financial institutions around the world.
There are a number of related information security policies that can help address this common threat. These include standard security configurations for desktop and mobile devices, regular updates of virus and malicious software signatures, regular scanning of networked systems, and user education and awareness on software downloading and responding to phishing emails (see Item #5).
5. Employee Security - Screening, Education and Awareness
It is unlikely that there will be a year when employee education and awareness would not be a top information security priority. From rogue insiders going undetected to employees accidentally downloading spyware from a phishing attack, users are always at the front lines of many attacks. It has been said so many times that we can be numb from hearing it – educated users are essential to any security program. And yet, organizational priorities to not always follow this basic premise. A 2008 study by the Computer Security Institute showed that the average organization spends less than 1% of their budget on security awareness.
There are a number of security policies that can help integrate information security responsibilities into the workforce. Some examples include the requirements for annual security training, quarterly awareness activities, the formal documentation of information security responsibilities for various job roles, and validation of these in formal job reviews.
5.1 - The Insider Threat
This special area of employee-related security deserves special attention.
An alarming number of breaches now involve malicious employees or contractors. The breaches range from cases of espionage, to the simple pilfering of customer data for personal gain. According the ITRC report, insider theft - now at 15.7% of all breaches - has more than doubled between 2007 and 2008.
In one of the largest insider incidents of 2008, a former Countrywide Financial Corp. senior financial analyst was arrested and charged by the FBI for stealing and selling sensitive personal information of an estimated 2 million mortgage loan applicants. The data was taken over a two year period and sold to competitors. In March 2008, a former bank programmer at Compass Bank was charged after he had stolen a hard drive with 1 million customer records and used it to commit debit-card fraud.
A recent case involved a database administrator of a UK company, who was fined and sentenced to three months in jail after hacking into his former employer’s computer system. Later investigation revealed that the man had lied on his resume and also had prior criminal charges.
Written security policies can also help address the growing insider threat, and must focus on the entire lifecycle of employees and contractors. Examples include screening of employees in positions of trust, regular review of access rights, integration of security roles into job descriptions, monitoring of systems for unusually large transactions, and post-employment removal of logical and physical access rights.
Summary
So there are our top five categories. They are certainly not comprehensive, but they can give you a start on your priorities for 2009.
So what can we learn from this list? First, most data breaches involve a variety of factors, including both people and technology. So a variety of controls are required to help reduce the risk of these incidents. As we see from the analysis, most security policies are dependent on other policies to be completely effective. Privacy policies, encryption policies and backup policies must work together to prevent a breach involving stored sensitive data. User awareness and training policies must worth with malicious software detection and configuration control to help stop identity theft and the spread of botnets.
That is why Information Shield strives to provide the most comprehensive library of information security policies available. If your organization has gaps in any of these key areas, we encourage you to take a look at our security policy products. We look forward to serving you in 2009.
Effective Security Policy Management - Part 1
How mature is your information security policy program? Do you have a set of outdated documents stored in a binder or intranet site? Or do you have a documented management program that keeps your policies up to date, your users informed and your internal auditors sleeping at night?
This is the first article in the series: Seven Elements of an Effective Information Secrurity Policy Management Program. (Find more on this in our Security Policy Whitepapers) In this series we review seven key characteristics of an effective policy management program. These characteristics are culled from leading practices, security and privacy frameworks, and incidents involving information security policies. Organizations can use this quick checklist to evaluate the maturity of their existing management program.
Part 1: Written documents with version control
Even though it seems obvious, nearly every information security standard and framework specifically requires information security policies to be written. Since security policies define management’s expectations and stated objectives for protecting information, policies cannot be “implied” – but have to be documented. Having a “written policy document” is the first key control established within the international standard ISO/IEC 1-7799:2005, and is critical to performing both internal and external audits. But what are some characteristics that make for an effectively-written policy document?
Policy documents should be written in plain and simple language. Many information security and privacy policies are written in legalese that is difficult for end users to read and understand. Since user education and training is a key component of all information security frameworks, clear, user-oriented language is critical. If your information security policies are written by either the information technology (IT) or legal department, make sure you employ a technical writer or other editor who can help simplify the language of your documents.
Policy documents should also have a standard format so that they can be effectively managed and updated. The standard format not only enforces consistency among documents, it ensures that each document contains key elements that facilitate the overall management of the information security policies, such as the owner/author, title, scope and effective dates of the policy. Written documents should also have a policy version number. A policy version number clearly articulates which version of the policy is in force at the time of publication, and helps maintain a version history of each document. Maintaining a version history is not only good practice for preserving digital evidence in case of a lawsuit, it also demonstrates that the organization was performing due-diligence by updating its security policies on a regular basis.
In order to facilitate a clear document history that can be reviewed by auditors, some form of access-controlled document management system should be used. It can be as simple as folders on a network drive or a full-blown document management system. Complete systems usually provide a detailed audit trail of all changes and updates to documents.
This is the first article in the series: Seven Elements of an Effective Information Secrurity Policy Management Program. (Find more on this in our Security Policy Whitepapers) In this series we review seven key characteristics of an effective policy management program. These characteristics are culled from leading practices, security and privacy frameworks, and incidents involving information security policies. Organizations can use this quick checklist to evaluate the maturity of their existing management program.
Part 1: Written documents with version control
Even though it seems obvious, nearly every information security standard and framework specifically requires information security policies to be written. Since security policies define management’s expectations and stated objectives for protecting information, policies cannot be “implied” – but have to be documented. Having a “written policy document” is the first key control established within the international standard ISO/IEC 1-7799:2005, and is critical to performing both internal and external audits. But what are some characteristics that make for an effectively-written policy document?
Policy documents should be written in plain and simple language. Many information security and privacy policies are written in legalese that is difficult for end users to read and understand. Since user education and training is a key component of all information security frameworks, clear, user-oriented language is critical. If your information security policies are written by either the information technology (IT) or legal department, make sure you employ a technical writer or other editor who can help simplify the language of your documents.
Policy documents should also have a standard format so that they can be effectively managed and updated. The standard format not only enforces consistency among documents, it ensures that each document contains key elements that facilitate the overall management of the information security policies, such as the owner/author, title, scope and effective dates of the policy. Written documents should also have a policy version number. A policy version number clearly articulates which version of the policy is in force at the time of publication, and helps maintain a version history of each document. Maintaining a version history is not only good practice for preserving digital evidence in case of a lawsuit, it also demonstrates that the organization was performing due-diligence by updating its security policies on a regular basis.
In order to facilitate a clear document history that can be reviewed by auditors, some form of access-controlled document management system should be used. It can be as simple as folders on a network drive or a full-blown document management system. Complete systems usually provide a detailed audit trail of all changes and updates to documents.
Thursday, August 21, 2008
Information Security Policies and BITS Assessment
The events of 2007 and 2008 have led to an increased focus on governance, security and privacy within the financial services market. One increasingly common scenario is when a third-party service provider must have their security program validated by the financial institution that it serves.
Historically, these audits were based on the BITS framework and have been somewhat painful for both the service providers and the financial organizations due to a lack of standardization. While BITS provided an overall framework, the specific assessment methods and questionnaires varied widely between organizations and projects.
An initiative called the "The Financial Institution Shared Assessments Program " aims to bring some order and consistency to these audits. The program was created by BITS and member financial institutions to fix the cumbersome and expensive service provider assessment process. The shared assessments are managed and promoted by the BITS consortium and the Sante Fe Group.
Many organizations that are subject to these assessments discover weaknesses in written security policies. For example, one of the major BITS/Shared Assessment control areas is "Asset Classification and Control." Within the guidance for this section, one of the documents that may be requested for verification is a written Asset Control Policy.
For these organizations, Information Security Policies Made Easy and the PolicyShield Security Policy Subcription can help fill in the gaps with high-quality, pre-written security policies. Using Data Classification as an example, ISPME provides over 100 pre-written policy statements relating to the classification, labeling, and management of assets. It also includes a sample, pre-written "Data Classification Policy" that can easily be customized with a minimum of effort.
ISPME and PolicyShield provide pre-written policy-level controls for each section of the BITS/Shared Asssessment framework. Organizations can save hundreds of man-hours by customizing ISPME policies versus creating them from scratch. Since ISPME is organized around ISO 17799, there is an easy mapping between the BITS requirements and the security policies with ISPME.
Historically, these audits were based on the BITS framework and have been somewhat painful for both the service providers and the financial organizations due to a lack of standardization. While BITS provided an overall framework, the specific assessment methods and questionnaires varied widely between organizations and projects.
An initiative called the "The Financial Institution Shared Assessments Program " aims to bring some order and consistency to these audits. The program was created by BITS and member financial institutions to fix the cumbersome and expensive service provider assessment process. The shared assessments are managed and promoted by the BITS consortium and the Sante Fe Group.
Many organizations that are subject to these assessments discover weaknesses in written security policies. For example, one of the major BITS/Shared Assessment control areas is "Asset Classification and Control." Within the guidance for this section, one of the documents that may be requested for verification is a written Asset Control Policy.
For these organizations, Information Security Policies Made Easy and the PolicyShield Security Policy Subcription can help fill in the gaps with high-quality, pre-written security policies. Using Data Classification as an example, ISPME provides over 100 pre-written policy statements relating to the classification, labeling, and management of assets. It also includes a sample, pre-written "Data Classification Policy" that can easily be customized with a minimum of effort.
ISPME and PolicyShield provide pre-written policy-level controls for each section of the BITS/Shared Asssessment framework. Organizations can save hundreds of man-hours by customizing ISPME policies versus creating them from scratch. Since ISPME is organized around ISO 17799, there is an easy mapping between the BITS requirements and the security policies with ISPME.
Monday, October 29, 2007
Policy Sound-Off - Responding to Email Requests
Phishers are coming up with increasingly sophisticated ways to encourage corporate users to open emails. Two recent incidents using two different attack methods help illustrate the increased threat.
In the first, a large retail grocery chain narrowly escaped a $10 million loss when employees were instructed via email to begin depositing funds to a new bank account for two existing vendors. In this case of very narrow “spear phishing” the attackers clearly had specialized knowledge about the company operations that made the emails seem legitimate. They targeted specific individuals within one organization, making detection more difficult.
Another recent phishing attack involves fake email messages claiming to come from the Equal Employment Opportunity Comm (EEOC). In this attack, the fake emails claim to be notifying the company of an employee complaint made against the organization. This is one of the many examples of phishers playing on the desire of employees to comply with state and federal legislation. In these attacks, many organizations are targeted but with a more credible-sounding business message. In both the narrow and broad approaches, attacks are getting more sophisticated and often contain logos and content that is stolen directly from the organization being spoofed in the emails.
Does your organization have a formal policy on how your employees and contractors should respond to external requests for sensitive information? Are employees educated on the various types of phishing attacks, including where and how to report a suspected attack?
(Note: For organizations that wish to include phishing attacks in their formal training and awareness programs, the January 2008 issue of Protecting Information will cover social engineering in more detail.)
In the first, a large retail grocery chain narrowly escaped a $10 million loss when employees were instructed via email to begin depositing funds to a new bank account for two existing vendors. In this case of very narrow “spear phishing” the attackers clearly had specialized knowledge about the company operations that made the emails seem legitimate. They targeted specific individuals within one organization, making detection more difficult.
Another recent phishing attack involves fake email messages claiming to come from the Equal Employment Opportunity Comm (EEOC). In this attack, the fake emails claim to be notifying the company of an employee complaint made against the organization. This is one of the many examples of phishers playing on the desire of employees to comply with state and federal legislation. In these attacks, many organizations are targeted but with a more credible-sounding business message. In both the narrow and broad approaches, attacks are getting more sophisticated and often contain logos and content that is stolen directly from the organization being spoofed in the emails.
Does your organization have a formal policy on how your employees and contractors should respond to external requests for sensitive information? Are employees educated on the various types of phishing attacks, including where and how to report a suspected attack?
(Note: For organizations that wish to include phishing attacks in their formal training and awareness programs, the January 2008 issue of Protecting Information will cover social engineering in more detail.)
Wednesday, September 26, 2007
Security Policy on Social Networking Sites
Social Networking sites present some unique challenges for organizations that must attract and keep young workers. Is the use of social networking sites at work a necessary perk or an unacceptable risk to corporate information? Some argue that organizations must allow access to social networking and other Web 2.0 sites to help attract a more "fickly" twenty-something workforce that are used to life online. Others say that the risks are simply too great, both in terms of wasted time and potential for infected computers.
The Fall 2007 issue of the security awareness newsletter Protecting Information covers the most common risks of social networking sites. In the issue Rebecca Herold describes several incidents where employees were terminated based on content posted on their personal pages on various social networking sites. Clearly this issue is going to grow as fast as the number of people that use social networking sites - now estimated at over 200 million.
Does your organization block social networking sites? Is social networking addressed within your information security policies? What are some of the concerns that you feel should be addressed in policy?
The Fall 2007 issue of the security awareness newsletter Protecting Information covers the most common risks of social networking sites. In the issue Rebecca Herold describes several incidents where employees were terminated based on content posted on their personal pages on various social networking sites. Clearly this issue is going to grow as fast as the number of people that use social networking sites - now estimated at over 200 million.
Does your organization block social networking sites? Is social networking addressed within your information security policies? What are some of the concerns that you feel should be addressed in policy?
Monday, September 17, 2007
Effective Security Policy Management - Part 2
Part 2 of 7: Seven Elements of an Effective Information Security Policy Management Program
Effective Security Policies Part 2. Defined Policy Document Ownership
Security Policies can be viewed as contract between senior management, employees and third-parties about the ways in which the organization will protect information. By definition, a contract is between parties, and in the case of written security and privacy policies one of the parties is always senior management.
Each written security policy document should have a defined owner and/or author. This statement of ownership is the tie between the written policies and the acknowledgement of management’s responsibility for updating and maintaining information security policies. The policy author also provides a point of contact if anyone in the organization has a question about specific policies. Many organizations have written information security policies that are so out-of-date that the author is no longer employed by the organization.
Another area of responsibility that should be documented within written security policies is the executive sponsor. The executive sponsor is a C-level manager or executive that puts the final “stamp of approval” on each document. A high-level executive sponsor demonstrates to all employees that your organization is serious about information security in general, and security policies in particular. Ideally, this is the CEO or equivalent top executive within the organization. In some larger organizations, this might be the head of large region or perhaps the Chief Operating Officer. Within the requirements of Sarbanes-Oxley, senior management must actually sign a written document attesting to the adequacy of the organization's internal controls. Written policies are a key part of these internal controls.
In some cases, the executive sponor is listed as part of each published policy document. In other cases, the sponsoring executive may issue a seperate memorandum stating the importance of information security and that following published policies is required for continued employement within the company.
Effective Information Security Policy Management - Part 1
How mature is your information security policy program? Do you have a set of outdated documents stored in a binder or intranet site? Or do you have a documented management program that keeps your policies up to date, your users informed and your internal auditors sleeping at night?
This is the first article in the series: Seven Elements of an Effective Information Security Policy Management Program. In this series we review seven key characteristics of an effective policy management program. These characteristics are culled from leading practices, security and privacy frameworks, and incidents involving information security policies. Organizations can use this quick checklist to evaluate the maturity of their existing management program.
Part 1: Written documents with version control
Even though it seems obvious, nearly every information security standard and framework specifically requires information security policies to be written. Since security policies define management’s expectations and stated objectives for protecting information, policies cannot be “implied” – but have to be documented. Having a “written policy document” is the first key control established within the international standard ISO/IEC 1-7799:2005, and is critical to performing both internal and external audits. But what are some characteristics that make for an effectively-written policy document?
Policy documents should be written in plain and simple language. Many information security and privacy policies are written in legalese that is difficult for end users to read and understand. Since user education and training is a key component of all information security frameworks, clear, user-oriented language is critical. If your information security policies are written by either the information technology (IT) or legal department, make sure you employ a technical writer or other editor who can help simplify the language of your documents.
Policy documents should also have a standard format so that they can be effectively managed and updated. The standard format not only enforces consistency among documents, it ensures that each document contains key elements that facilitate the overall management of the information security policies, such as the owner/author, title, scope and effective dates of the policy.
Written documents should also have a policy version number. A policy version number clearly articulates which version of the policy is in force at the time of publication, and helps maintain a version history of each document. Maintaining a version history is not only good practice for preserving digital evidence in case of a lawsuit, it also demonstrates that the organization was performing due-diligence by updating its security policies on a regular basis.
In order to facilitate a clear document history that can be reviewed by auditors, some form of access-controlled document management system should be used. It can be as simple as folders on a network drive or a full-blown document management system. Complete systems usually provide a detailed audit trail of all changes and updates to documents.
Monday, August 27, 2007
Required Acknowledgement of Security Policy Changes
Legal precedents are beginning to dictate a new standard for the notification of policy changes to your customers and employees. In the "old days" organizations would post changes to information security policies on the corporate intranet, and perhaps even notify employees that these changes occurred via email or some other means. However, in legal actions where employees were terminated for violating policy and then sued for improper termination, the conclusion was that mere notification is not enough. Organizations are expected to notify employees of important policy changes, but must go a step further and verify acknowledgement by employees affected by the change.
A recent case with a telecommunications provider seems to indicate that this standard applies to customers as well. The typical line in many online privacy policies goes something like "we reserve to change this policy at any time." While this practice is common, it is certainly not in the spirit of “open” communication with customers as outlined in OECD Privacy Principles. This ruling came as part of a class-action lawsuit where customers sued for terms of service changes that were applied automatically to their account. However, it seems likely that an equal case could be made for changes to privacy policies that would effect the collection of personal information.
I believe it is now "best practice" to require acknowledgement of important security and privacy policy changes. I am interested to hear if this is becoming standard practice in real organizations, or just the unrealistic musings of a policy "purist."
A recent case with a telecommunications provider seems to indicate that this standard applies to customers as well. The typical line in many online privacy policies goes something like "we reserve to change this policy at any time." While this practice is common, it is certainly not in the spirit of “open” communication with customers as outlined in OECD Privacy Principles. This ruling came as part of a class-action lawsuit where customers sued for terms of service changes that were applied automatically to their account. However, it seems likely that an equal case could be made for changes to privacy policies that would effect the collection of personal information.
I believe it is now "best practice" to require acknowledgement of important security and privacy policy changes. I am interested to hear if this is becoming standard practice in real organizations, or just the unrealistic musings of a policy "purist."
New legislation may help prosecution of ID theft
Companies that have their identities used in phishing scams have little recorse in stopping the attacks. However, new legislation proposed by the Justice Department would expand the ability of enforcement agencies to prosecute identity theft, and adds provisions that may help corporations who are used in phishing scams.
The "Identity Theft Enforcement and Restitution Act of 2007" would expand the reach of federal law to criminal activity that currently “slips through the cracks” of existing federal law. Among the many provisions, the law would increase the ability of the federal government to prosecute criminals by expanding the definitions of the criminal activity that defined “identify theft” and by addressing specific technologies such as spyware and keystroke logging. The bill would also expand the rights of victims to seek restitution for the hours spent recovering from ID theft.
Several provisions introduced in the bill may help corporations fight identify theft. For example, the law would close gaps in two federal statutes by making it illegal to use not just a person's identification but also the identification of a corporation or organization “such as the name, logo, trademark”, as is common in phishing attacks. Other language closes more gaps related to cyber-extortion as covered in the Computer Fraud and Abuse Act, by including threats “to steal or corrupt data on a victim's computer, or not repair damage the offender already caused to the computer."
The "Identity Theft Enforcement and Restitution Act of 2007" would expand the reach of federal law to criminal activity that currently “slips through the cracks” of existing federal law. Among the many provisions, the law would increase the ability of the federal government to prosecute criminals by expanding the definitions of the criminal activity that defined “identify theft” and by addressing specific technologies such as spyware and keystroke logging. The bill would also expand the rights of victims to seek restitution for the hours spent recovering from ID theft.
Several provisions introduced in the bill may help corporations fight identify theft. For example, the law would close gaps in two federal statutes by making it illegal to use not just a person's identification but also the identification of a corporation or organization “such as the name, logo, trademark”, as is common in phishing attacks. Other language closes more gaps related to cyber-extortion as covered in the Computer Fraud and Abuse Act, by including threats “to steal or corrupt data on a victim's computer, or not repair damage the offender already caused to the computer."
Thursday, August 09, 2007
Contractors fined for not following security policy
In July 2007, several contractors of Los Alamos National Laboratory were fined a total of $3.3 million for failing to adequately protect data as required in their contracts. The Department of Energy (DOE) initiated formal enforcement actions against specific current and former contractors, the reports said that investigations revealed that the contractors failed to prevent "a subcontractor employee's unauthorized reproduction of and removal of classified matter from the site." The DOE also issued a Compliance Order to Los Alamos, requiring corrective action to increase physical protection and cyber-security to safeguard classified information.
This is another example that illustrates the importance of two areas of security policy related to third-party contractors. First, information security requirements should be included in all written contracts (apparently so in this case). Second, the organization must establish procedures for periodic monitoring of all third-party contractors for compliance with information security policies. Information security policies made easy includes over 100 separate security policy controls for managing third-party relationships.
This is another example that illustrates the importance of two areas of security policy related to third-party contractors. First, information security requirements should be included in all written contracts (apparently so in this case). Second, the organization must establish procedures for periodic monitoring of all third-party contractors for compliance with information security policies. Information security policies made easy includes over 100 separate security policy controls for managing third-party relationships.
Regulatory Requirements for Information Security Policies
Some organizations still receive little management support or funding for a sound information security policy program. Within the last several years, however, numerous federal, state and international regulations have been passed that require the protection of information. Many organizations are now enhancing their information security policies in response to legal and regulatory requirements.
In some cases, these regulations are very specific about the requirements for written security and privacy policies. In other cases, a regulation simply requires safeguards that are "appropriate" for the size and type of organization. In these cases, enforcement agencies and auditors must defer to accepted best practices or frameworks for guidance, all of which require written policies. Examples of these are the Generally Accepted Information Security Principles (GAISP), Control Objectives for Information Technology (COBIT®) and ISO/IEC 17799.
This information security policy requirements table contains a partial list of security or privacy-related regulations and their specific information security policy requirements. Where appropriate, the list includes the security policy requirements of several key frameworks used to manage compliance with various regulations. Organizations may use this table to help build a case to senior management that written security policies are "not just a good idea, they're the law."
In some cases, these regulations are very specific about the requirements for written security and privacy policies. In other cases, a regulation simply requires safeguards that are "appropriate" for the size and type of organization. In these cases, enforcement agencies and auditors must defer to accepted best practices or frameworks for guidance, all of which require written policies. Examples of these are the Generally Accepted Information Security Principles (GAISP), Control Objectives for Information Technology (COBIT®) and ISO/IEC 17799.
This information security policy requirements table contains a partial list of security or privacy-related regulations and their specific information security policy requirements. Where appropriate, the list includes the security policy requirements of several key frameworks used to manage compliance with various regulations. Organizations may use this table to help build a case to senior management that written security policies are "not just a good idea, they're the law."
Monday, October 30, 2006
Security Policy and Responsibility
Last month we discussed the security policy problems revealed within the department of Veteran's Affairs (VA) in the wake of the highly public data breach, including the firing of two employees responsible for information security. Over the last month, employees at both AOL and Ohio University were terminated or resigned in the aftermath of data privacy breaches. All of these cases point to some interesting security policy questions for all organizations to consider.
Security Scapegoats?
While termination seems to be an obvious step to attempt to restore customer confidence, in both cases serious questions were raised about the overall security and privacy practices of the entire organization. In the wake of very damaging or embarrassing data breaches, some organizations seem to focus the blame on individuals, rather than on weaknesses of internal policies and procedures.
In the past, similar incidents have resulted in lawsuits for improper termination, since many organizations failed to clearly communicate their data security and privacy policies to all employees. In the case of Ohio University, lawyers have already made statements for the fired employees indicating that they were improperly targeted. Similar statements were made by ex-employees of the VA.
Security Policy Lessons
These incidents and their public fall-out raise some important questions for organizations concerned with policy creation, education and enforcement:
Question: Do your information security policies cover sanctions against employees? Is the language in the policies specific to violation of existing corporate policies?
In neither of these cases did the public statements mention that employees were violating any specific policy, but instead seemed to indicate that the employees should have "known better." AOL CEO Jon Miller in an internal memo stated that "This incident took place because some employees did not exercise good judgment or review their proposal with our privacy team. We are taking appropriate action with the employees who were responsible."
The fundamental question here is whether or not an employee should be fired for making mistakes, especially in areas where there is very little official guidance on how employees can operate safely with sensitive data. While we are not attempting to judge the legality of such actions, evidence suggests that terminating employees without proper cause or documentation will create problems.
During a risk-assessment or policy update phase, organizations would do well to consider what would happen in their own organization if an individual makes a mistake that causes an information security and privacy breach. What should be done if the organizational policies only address violation of stated policy?
Question: Does your organization clearly communicate information security and privacy policies to users based on their role in the organization?
Organizations that wish to terminate employees for violation for company policy should take great care to have their information security and privacy policies clearly documented and communicated.
In the case of AOL, it is not clear if there was a corporate privacy policy that prohibited researchers from using data without consulting the privacy group. But other data casts some doubt. Public statements by AOL suggest that they are now taking a serious look at their internal policies. Public response to the AOL incident included allegations that sensitive search data should be destroyed as part of a regular data destruction policy.
In a separate statement, Ohio University announced a 20-point plan to improve information security at the school, which has about 16,640 undergraduate students and 862 full-time faculty members on its Athens campus.
Question: Are information security and privacy responsibilities clearly documented in job responsibilities?
In the case of the VA and Ohio University, the terminated employees had direct responsibility for information security. Even so, statements from the attorneys of fired employees seem to raise some questions as to which systems the individuals were responsible for.
In the case of AOL, the employees were doing research on web searches. Company statements indicate that there were no official procedures in place for protecting customer privacy, but that the employees "were to consult the privacy team" before posting their research.
While we can only extrapolate from these public statements, the common thread is all of these cases is a poor documentation of information security responsibilities. While have information security policies is critical, they are much more effective when they are tied to specific responsibilities of various job roles. Organizations that take this more structured approach will not only have better security, but will be better prepared for any sanctions.
Resources
Information Security Policies Made Easy, Version 10 - A complete library of information security policies, including policies for personnel security.
Information Security Roles & Responsibilities Made Easy, Version 2 - An extensive library of documented information security requirements for various organizational roles.
Privacy Management Toolkit, Version 1 - A complete resource for managing customer and employee privacy based on OECD Fair Information Principles.
Security Scapegoats?
While termination seems to be an obvious step to attempt to restore customer confidence, in both cases serious questions were raised about the overall security and privacy practices of the entire organization. In the wake of very damaging or embarrassing data breaches, some organizations seem to focus the blame on individuals, rather than on weaknesses of internal policies and procedures.
In the past, similar incidents have resulted in lawsuits for improper termination, since many organizations failed to clearly communicate their data security and privacy policies to all employees. In the case of Ohio University, lawyers have already made statements for the fired employees indicating that they were improperly targeted. Similar statements were made by ex-employees of the VA.
Security Policy Lessons
These incidents and their public fall-out raise some important questions for organizations concerned with policy creation, education and enforcement:
Question: Do your information security policies cover sanctions against employees? Is the language in the policies specific to violation of existing corporate policies?
In neither of these cases did the public statements mention that employees were violating any specific policy, but instead seemed to indicate that the employees should have "known better." AOL CEO Jon Miller in an internal memo stated that "This incident took place because some employees did not exercise good judgment or review their proposal with our privacy team. We are taking appropriate action with the employees who were responsible."
The fundamental question here is whether or not an employee should be fired for making mistakes, especially in areas where there is very little official guidance on how employees can operate safely with sensitive data. While we are not attempting to judge the legality of such actions, evidence suggests that terminating employees without proper cause or documentation will create problems.
During a risk-assessment or policy update phase, organizations would do well to consider what would happen in their own organization if an individual makes a mistake that causes an information security and privacy breach. What should be done if the organizational policies only address violation of stated policy?
Question: Does your organization clearly communicate information security and privacy policies to users based on their role in the organization?
Organizations that wish to terminate employees for violation for company policy should take great care to have their information security and privacy policies clearly documented and communicated.
In the case of AOL, it is not clear if there was a corporate privacy policy that prohibited researchers from using data without consulting the privacy group. But other data casts some doubt. Public statements by AOL suggest that they are now taking a serious look at their internal policies. Public response to the AOL incident included allegations that sensitive search data should be destroyed as part of a regular data destruction policy.
In a separate statement, Ohio University announced a 20-point plan to improve information security at the school, which has about 16,640 undergraduate students and 862 full-time faculty members on its Athens campus.
Question: Are information security and privacy responsibilities clearly documented in job responsibilities?
In the case of the VA and Ohio University, the terminated employees had direct responsibility for information security. Even so, statements from the attorneys of fired employees seem to raise some questions as to which systems the individuals were responsible for.
In the case of AOL, the employees were doing research on web searches. Company statements indicate that there were no official procedures in place for protecting customer privacy, but that the employees "were to consult the privacy team" before posting their research.
While we can only extrapolate from these public statements, the common thread is all of these cases is a poor documentation of information security responsibilities. While have information security policies is critical, they are much more effective when they are tied to specific responsibilities of various job roles. Organizations that take this more structured approach will not only have better security, but will be better prepared for any sanctions.
Resources
Information Security Policies Made Easy, Version 10 - A complete library of information security policies, including policies for personnel security.
Information Security Roles & Responsibilities Made Easy, Version 2 - An extensive library of documented information security requirements for various organizational roles.
Privacy Management Toolkit, Version 1 - A complete resource for managing customer and employee privacy based on OECD Fair Information Principles.
Policy Controls for Building Secure Applications
A number of recent surveys indicate that an increasing number of attacks are targeting applications, rather than operating systems. Hackers have discovered that applications are patched far less frequently than operating systems and web servers. For example, the recent release of the SANS Top 20 vulnerabilities of 2005 points to a number of problems related to application security. The results prompted SANS Institute Research Director Allan Paller to state that "Security has been set back nearly six years in the past 18 months" because of problems with application patching.
Application security weaknesses are now under tremendous scrutiny within commercial software. For years, commercial software vendors have been under fire for not developing secure code and then not fixing flaws fast enough once they are discovered. Applications that effect large number of users, such as email clients and web browsers, have been the focus of much coverage in the news. While commercial software is certainly a large problem, often overlooked are the applications that are developed in-house.
Many organizations that are assessing their internal controls for Sarbanes-Oxley or other compliance efforts are discovering that many in-house applications (as well as those developed by commercial vendors) are lacking in basic security controls. To help reduce the overall corporate risk, compensating controls in the form of manual procedures will need to be implemented. As organizations are beginning to see, the cost of not building security into applications from the beginning can be very many times the cost of manual compensating controls.
Policy-based controls
There are a number of internal control points that make sense to address with policies and procedures. First, is to have an overall policy that concisely establishes security as part of the overall application development process. For example:
Policy: For all business application systems, systems designers and developers must consider security from the beginning of the systems design process through conversion to a production system.
Of course, this policy is equally valid for any development undertaken by the company, either using in-house or contracted staff. A similar policy should be implemented for the acquisition of new systems from third party or commercial vendors. So what some of the organizational standards and procedures that will support this policy?
Security Requirements Reviews - Applications usually begin with a set of requirements. The first step is to review system requirements document for security, and putting specific security controls in the application from the design phase. If you organization has a formal project development process, a formal security review checkpoint should be established.
With all of the procedures mentioned here, it is important to understand the implied personnel responsibilities. A person or team in the organization should be designated to review applications for security requirements. These can either be members of the development staff training in information security practices, or members of the information security team with specific knowledge of application development issues.
Secure Coding Practices - Once requirements have been defined, design and coding begins. At this point, developers begin the process of turning ideas into code. Ideally, developers should be trained in secure coding practices. However, more realistic would be to have one or two senior developers or system architects that can participate in code reviews and coach other team members. For example, these lead developers can establish a set of secure coding "best practices" that get distributed to all development staff.
Testing for Security Features - Assuming that security features where included in the system requirements documents, these features would then generate test cases for system and integration testing. The more complicated the application, the more opportunity there is for vulnerabilities to be created by unanticipated combinations of system state, or assumptions of secure messaging that may get compromised. Again, the testing team should have key members who are trained in developing cases that test availability, confidentiality and data integrity, including error and recovery states. Testing may also include disaster recovery scenarios, such as how to recover the application state from a complete system failure.
Application Vulnerability Analysis - Finally, some organizations may consider performing "white-hat" vulnerability analysis on their own systems. In this scenario, team members or outside consultants who are familiar with system vulnerability can try to "hack" the applications systems in a test environment. This process may expose vulnerability associated with operating system or network configuration flaws that were impossible to anticipate during the design phase.
Conclusion - Have procedures to support your policies
It is important to have policies in place that require security in the application development and acquisition process. However, if your internal procedures are not modified to support the policy, there is no way for the policy to have any impact on the organization. A little bit of homework, and some targeted training for key staff members will help insure that your applications are developed with security in mind. Secure applications will not only make your customers happy, they may keep you out of the headlines.
Related Resources and Information
Information Security Policies Made Easy, Version 10.0 contains over 1300 pre-written policies, including policies for application development and system acquisition. If you have any gaps in your incident policies, this is the most cost-effective way to fill them.
Application security weaknesses are now under tremendous scrutiny within commercial software. For years, commercial software vendors have been under fire for not developing secure code and then not fixing flaws fast enough once they are discovered. Applications that effect large number of users, such as email clients and web browsers, have been the focus of much coverage in the news. While commercial software is certainly a large problem, often overlooked are the applications that are developed in-house.
Many organizations that are assessing their internal controls for Sarbanes-Oxley or other compliance efforts are discovering that many in-house applications (as well as those developed by commercial vendors) are lacking in basic security controls. To help reduce the overall corporate risk, compensating controls in the form of manual procedures will need to be implemented. As organizations are beginning to see, the cost of not building security into applications from the beginning can be very many times the cost of manual compensating controls.
Policy-based controls
There are a number of internal control points that make sense to address with policies and procedures. First, is to have an overall policy that concisely establishes security as part of the overall application development process. For example:
Policy: For all business application systems, systems designers and developers must consider security from the beginning of the systems design process through conversion to a production system.
Of course, this policy is equally valid for any development undertaken by the company, either using in-house or contracted staff. A similar policy should be implemented for the acquisition of new systems from third party or commercial vendors. So what some of the organizational standards and procedures that will support this policy?
Security Requirements Reviews - Applications usually begin with a set of requirements. The first step is to review system requirements document for security, and putting specific security controls in the application from the design phase. If you organization has a formal project development process, a formal security review checkpoint should be established.
With all of the procedures mentioned here, it is important to understand the implied personnel responsibilities. A person or team in the organization should be designated to review applications for security requirements. These can either be members of the development staff training in information security practices, or members of the information security team with specific knowledge of application development issues.
Secure Coding Practices - Once requirements have been defined, design and coding begins. At this point, developers begin the process of turning ideas into code. Ideally, developers should be trained in secure coding practices. However, more realistic would be to have one or two senior developers or system architects that can participate in code reviews and coach other team members. For example, these lead developers can establish a set of secure coding "best practices" that get distributed to all development staff.
Testing for Security Features - Assuming that security features where included in the system requirements documents, these features would then generate test cases for system and integration testing. The more complicated the application, the more opportunity there is for vulnerabilities to be created by unanticipated combinations of system state, or assumptions of secure messaging that may get compromised. Again, the testing team should have key members who are trained in developing cases that test availability, confidentiality and data integrity, including error and recovery states. Testing may also include disaster recovery scenarios, such as how to recover the application state from a complete system failure.
Application Vulnerability Analysis - Finally, some organizations may consider performing "white-hat" vulnerability analysis on their own systems. In this scenario, team members or outside consultants who are familiar with system vulnerability can try to "hack" the applications systems in a test environment. This process may expose vulnerability associated with operating system or network configuration flaws that were impossible to anticipate during the design phase.
Conclusion - Have procedures to support your policies
It is important to have policies in place that require security in the application development and acquisition process. However, if your internal procedures are not modified to support the policy, there is no way for the policy to have any impact on the organization. A little bit of homework, and some targeted training for key staff members will help insure that your applications are developed with security in mind. Secure applications will not only make your customers happy, they may keep you out of the headlines.
Related Resources and Information
Information Security Policies Made Easy, Version 10.0 contains over 1300 pre-written policies, including policies for application development and system acquisition. If you have any gaps in your incident policies, this is the most cost-effective way to fill them.
Thursday, March 09, 2006
COBIT or ISO17799?
Many organizations just getting started with information security policies ask us the question: Should we use ISO 17799 or COBIT? The answer, of course, is that it depends on what you are trying to accomplish. In fact, they are not mutually exclusive, but can be used together.
The basic difference between COBIT and ISO17799:2005 is that ISO 17799 is only focused on information security, whereas COBIT is focused on more general information technology controls. Thus, COBIT has a broader coverage of general information technology topics, but does not have as many detailed information security requirements as ISO 17799:2005. If an organization addresses all of the security controls within ISO 17799:2005, then they will be covering a large part of COBIT in the process - especially the section DS5 Ensure Systems Security. However, COBIT covers a much larger set of issues related to information technology "governance," and is typically used as part of an overall corporate governance framework.
Organizations that must comply with overall corporate governance requirements such as Sarbanes-Oxley (in the US) or Basel II (international banking) tend to use COBIT, whereas organizations focused primarily on information security may use ISO 17799. As of late 2005, organizations can now get certified against the ISO 17799:2005 standard. This certification is based on the existing BS 7799 standard, and has now been adoped by ISO. So if your organization desires a security certification, ISO 17799:2005 would be an appropriate choice.
COBIT (Control Objectives for Information Technology) is published by ISACA and the IT Governance Institute. ISO 17799:2005 is available from BSI or ANSI. For more information, see our compliance information at http://www.informationshield.com/compliance.html.
The basic difference between COBIT and ISO17799:2005 is that ISO 17799 is only focused on information security, whereas COBIT is focused on more general information technology controls. Thus, COBIT has a broader coverage of general information technology topics, but does not have as many detailed information security requirements as ISO 17799:2005. If an organization addresses all of the security controls within ISO 17799:2005, then they will be covering a large part of COBIT in the process - especially the section DS5 Ensure Systems Security. However, COBIT covers a much larger set of issues related to information technology "governance," and is typically used as part of an overall corporate governance framework.
Organizations that must comply with overall corporate governance requirements such as Sarbanes-Oxley (in the US) or Basel II (international banking) tend to use COBIT, whereas organizations focused primarily on information security may use ISO 17799. As of late 2005, organizations can now get certified against the ISO 17799:2005 standard. This certification is based on the existing BS 7799 standard, and has now been adoped by ISO. So if your organization desires a security certification, ISO 17799:2005 would be an appropriate choice.
COBIT (Control Objectives for Information Technology) is published by ISACA and the IT Governance Institute. ISO 17799:2005 is available from BSI or ANSI. For more information, see our compliance information at http://www.informationshield.com/compliance.html.
Sunday, November 06, 2005
Welcome to the Information Security Policy Weblog
The Information Security Policy Weblog is published by Information Shield. We provide this weblog (aka blog) to share and discuss various ideas that relate to the protection of both corporate and personal information through information security policies. We hope this will provide a forum to discuss real-world issues involving the practice of protecting information. We encourage your advice, comments, stories and feedback.
David Lineman
President
Information Shield, Inc.
David Lineman
President
Information Shield, Inc.
Subscribe to:
Posts (Atom)
Posts
