Continue reading »]]> Assessing the risk of third-party vendors has been a growing problem for compliance management.  Because of the growing number of data breaches related to third-parties, regulators have been focusing on the inherent risks of outsourcing.   Within the financial services industry, this has long been accomplished via a SAS70 (now SSAE16) type audit.

Within the U.S. healthcare industry, the Health Information Technology for Economic and Clinical Health Act (HITECH), enacted in early 2009, put enforcement teeth behind vendor breaches of medical records.   Among other requirements, it essentially extended the liability of Covered Entities under HIPAA to their Service Providers.  This created a flurry of activity as covered entities struggle to find ways to manage and assess the risk of hundreds or even thousands of vendors.

This month a milestone was reached, as the Department of Health and Human Services (HHS) took the first enforcement action for a breach under HiTECH.  As part of the enforcement,  BlueCross BlueShield of Tennessee, Inc., agreed to pay $1.5 million in fines as a result of the theft of 57 unencrypted hard drives taken from a data closet in a Chattanooga facility that was no longer in use by the company.

This is likely to be only the beginning.  Since 2010, reports to the HHS breach reporting site has averaged about 17 breaches per month, with over 500 reported so far.

Managing Third Party Risk with Information Security Policies

Written information security policies are an essential part of managing risks related to third-parties.  (The requirement for written policies is clearly spelled out within the HIPAA Security Rule.)  There are several key areas to consider when developing information security policy documents for vendors:

1. Vendor Approval and Establishment – The first step is to properly assess the risks of outsourcing to any third party vendors.  (This is broadly covered in ISO 6.2.1 Identification of risks related to external parties.)

2. Contract Management – All contracts with third-party vendors must include information security requirements.  (This topic is covered in ISO 27002 section 6.2.3 Addressing security in third party agreements.)  The types of security controls may depend heavily on the type of vendor and type if information being accessed by the vendor.    For example, Information Security Policies Made Easy has over 25 different controls related to vendor contract management.

3. Ongoing Monitoring – Once established, third-party vendors must be monitored for ongoing compliance, including any major changes to their business that may impact their performance.  (ISO 27002: 10.2.2 Monitoring and review of third party services) For example, HiTECH requires that Services Providers who experience a breach must notify the Covered Entities that they serve.

4. Contract Termination – This final phase of a vendor relationship is often overlooked.  Once a relationship is terminated, all access points between the vendor and the organization must be removed.  This includes removal of third-party user accounts.  In some cases, this is as basic as leaving confidential information behind on the vendor premises, as happened in the BlueCross incident.

In summary, organizations must consider the relationship with third-party vendors as a complete life-cycle.  Poor security controls during any phase of the relationship can expose the organizations to unnecessary risks.

Continue reading »]]>
The European Union recently released a set of draft recommendations for a major update to the current privacy framework that underpins Directive 95/46/EC. The changes would introduce a single set of rules on data protection, valid across the EU. The proposed changed give individuals more control over their personal information and would have a significant impact on any organization that processes data on EU citizens.

The report entitled “Safeguarding Privacy in a Connected World A European Data Protection Framework for the 21st Century” come after a new study on attitudes on data protection indicates growing concern over data privacy among the citizens of EU countries.

Some highlights of the guidance include:

1. Breach responsibility and accountability – companies would have to notify their clients of any theft or accidental release of personal data
2. Explicit Consent: Before a company reuses their personal data, individuals need to give that consent explicitly.  People would also have access to their own private data and be able to transfer it to another service provider more easily
3. List Removal:  The updates enforces the  ‘right to be forgotten’ – where people will be able to have their personal data deleted if a business or other organization has no legitimate reasons for keeping it
4. International Scope:  The updates apply EU rules when personal data is processed outside Europe.  People would be able to involve the national data protection authority in their country, even when their data is processed by a company based outside the EU.

Organization concerned with compliance must consider updating their information security and data privacy policies.

Continue reading »]]> The Privacy Rights Clearinghouse recently released their review of what they call the most significant data breaches of 2011. Even if you have read about each of these incidents before, they are worth reading again in summary form.  What is perhaps most striking is how the most basic security policies and procedures are often the ones that were ignored or not implemented in these major breaches.   So here is the quick summary of incident and matching security policies:

Sony PlayStation (April 27) -  External intrusion by hackers gained access to 101.6 million records, including 12 million unencrypted credit card numbers.

Control Failure:  Weak Passwords

Epsilon (April 2) – Epsilon, an email service provider for companies, reported a breach that affected approximately 75 client companies.  (Maybe the largest breach EVER when counting records)

Control Failure: Third Party Service Provider Security / Sensitive Information in the Cloud

Sutter Physicians Services (SPS) and Sutter Medical Foundation (SMF) (Nov. 16) – A company-issued desktop computer was stolen from SMF’s administrative offices

Control Failure:  Physical Security of Devices Holding Sensitive Data / Encryption of Sensitive Data during Storage

Texas Comptroller’s Office (April 11) – Information from three Texas agencies was discovered to be accessible on a public server.

Control Failures:  Change Control on Product Systems / Sensitive Information on Low Security Systems

Health Net (March 15) – Nine data servers containing the personal information of 1.9 million current and former policyholders went missing from Health Net’s data center.  The breach was reported to customers nearly 3 months late.

Control Failures:  Physical Access Control of Processing Facilities / Incident Response and Data Breach Notification Policies

Tricare Management Activity, Science Applications International Corporation (SAIC) (Sept. 30) – The car theft of backup tapes resulted in the exposure of protected health information from patients of military hospitals and clinics.

Control Failures:  Secure Transport of Sensitive Information / Encrypted Backups of Sensitive Information

The good news is that these controls are all part of the basic information security policies found in nearly all data protection frameworks, including ISO 27002 and NIST SP-800-53.  For sample information security policy templates that address all of these requirements, see Information Security Policies Made Easy.

Continue reading »]]> In September 2011 a security researcher purchased some used network equipment for about $30 USD from  Ebay.    Once the equipment was delivered, the researcher found that it used to belong to the UK National Air Traffic Services (NATS) and that loads of sensitive data was still stored on the device, including network IP addresses and passwords.  This is but the latest in a string of similar incidents (See footnote) related to the same problem:  Many businesses either (1) do not effectively erase electronic data at all or (2) forget to include the wide variety of modern equipment that has storage and needs to be effectively erased.

Combating this common problem involves implementing two types of security policies. First is the obvious policy that requires all types of storage devices to be sanitized before reuse or disposal.  This is the common security policy that you might find called for in many regulations.  Although considered common practice, this policy still requires that the organization specify the methods that must be used and the process be documented.

Consider the following sample information security policy that has been part of Information Security Policies Made Easy for many years:

Policy:  The Information Security Department must maintain an inventory of all Company X computer and network equipment that has been taken out of commission. This inventory must also reflect all actions taken to clear memory chips, hard drives, and other storage locations in this same equipment of all stored information.

Second is an additional, related policy that requires the organization to maintain an accurate inventory of all equipment that may store sensitive information.  This second policy is often overlooked, but helps management stay aware of the variety of new devices that have hard-drives or other forms of permanent or semi-permanent storage.  This policy could be implemented as part of an asset inventory, or as part of the process IT uses to issue new equipment.

Policy:  The Information Security Department must maintain an inventory of all Company X computer, office and network equipment that will store sensitive information.   

Together these policies will dramatically reduce the risk of equipment being accidentally lost in the shuffle of today’s complex IT environment.

Related Incidents involving discarded equipment:

Photocopier Disk Contains Sensitive Information

Used Blackberry Sold for Data

NASA Disk Not Cleaned

Policy Points:  Is there a policy for that?

This is part of series of articles where we discuss real-world incidents that were caused by missing or incomplete information security policies.    In most cases, the incident could have been avoided if the organization had implemented one or two security policies found within our standard security policy library.

Continue reading »]]> One of the most intriguing cyber-security stories ever is the recent hack and public smearing of information security from HB Gary by hacker group Anonymous. The incident relates to the WikiLeaks scandal, and the ongoing fear that major corporations might be the next victims of embarrassing document leaks. Tech writers Michael Riley and Brad Stone provide a detailed account of the entire episode in Bloomberg Businessweek.

But in a story packed with egos, headline-grabbing hacks, political connections, law firms and finger-pointing, one of the most interesting facts was buried deep in the details: What could have been a relatively harmless hack turned into a PR nightmare because the executives of HB Gary failed to follow one of the most basic information security policies – Don’t share passwords between systems.

The shared-password is becoming like the germ that killed the invading Martians in War of the Worlds. The tiny, invisible bug is able to quickly spread a vulnerability in one system to many others. Here is a group of established security professionals, with stellar credentials and capabilities to hack into complex systems with ease. And yet when it comes down to a simple rule like not sharing userids and passwords between two systems, they are just like the rest of us. Convenience trumps security.

Over a year ago, we published an updated policy in our PolicyShield library that went something like this: “Users must not reuse company login credentials on social networking sites.”

This security policy was basically an extension of a much older policy (prohibited sharing of passwords between systems) into the realm of the internet. The basic premise is that reverse engineering a password was much easier using all of the information available on social networking sites like Facebook. Indeed, within a few months after we published the policy a real incident happened where a compromised Facebook account led to a network intrusion.

The take of HB Gary and Anonymous worked in reverse. By hacking into a web-based application, Anonymous was able to gain access to userids and passwords that were re-used on social networks sites like Twitter – enabling Anonymous to send fake tweets and other offensive messages posing as the team from HB Gary.

So is there a lesson in this? It might be that when it comes to information security policies – we really do have to sweat the small stuff. We always need to be on the lookout for the newest, most complex threats. But we still cannot forget the basic foundations of information security.

Continue reading »]]> We hear reports of new data breaches almost daily. While most of them are fairly complex stories, they most always begin at some point with a human “insider” making a mistake. In fact, 2011 could be considered the “Year of the Insider.” From the RSA hack and Sony Playstation breach, to the Epsilon e-mail breach and the Oak Ridge Lab phishing attack, database breach announcements that started with insider mistakes have become common news. Malicious threats are also on the rise, as recently Bank of America was hit with over $10 million in losses due to a malicious insider.

But who IS the insider and how can we implement controls to help stop them? In this new Information Shield white paper, The Insider Threat – Security Policies to Reduce Risk, we break down the various attributes of the insider threat, and suggest some information security policies that can help reduce the likelihood of current and former employees causing harm to the organization. We illustrate some of these controls will sample policies from our security policy sample library.

Since the very notion of an insider threat involves the risk of people’s behavior, and since information security policies are design to impact behavior, it makes sense to look at the problem of the insider threat from the perspective of the “lifecycle” of an employee’s access to information. (This is represented in sections 8.1 to 8.3 of the ISO 27002 framework.)

Continue reading »]]> Plan First: We all know that it’s advisable to create a plan before undertaking a large and complex project. For instance, most reasonable people would not consider building a modern residential house, with plumbing, heating, electrical, lighting, and communications systems, if they did not first have a clear and specific plan (aka blueprint). Of course, all of these systems could be added-on after the house was built, but the result will look jury-rigged, function much less efficiently, and be subject to breakdown in ways that would not plague a well-planned house.

The writer of new or substantially revised information security policies faces a similar situation. Yet many of these policy writers, especially the ones new to the task, think they can just slap a few sentences together (ideally sentences copied out of somebody’s book or another organization’s policy statement). After they do this, they think they’re done, uttering words like “there you go.” Those who have been down the security policy development road before, particularly those who have revised policy statements written by others, well … to be kind, let’s just say they know better. The surprisingly high level of complexity in the modern information security environment is revealed in these moments.

So here’s the practical advice: to keep your job as well as your good reputation, if you’re writing information security policies, be sure to sketch out a plan for the structure of the policies before the policies themselves get written. This structure for policy statements should define the titles of, scopes of, and release dates of specific areas to be addressed in the information security policies.

Risk Assessment Directs: There are of course a few types of security policies that apply to everybody, such as an access control policy based on the need to know. Beyond those, things get a lot more complicated. The types of policies that need to be written will be reflected by a recent broadly scoped information security risk assessment. If, for instance, the risk assessment speaks to risks associated with the release of classified government information, then a set of policies consistent with the department of defense would be appropriate. Alternatively, if the risk assessment talks about the risk of unauthorized software copying, then a separate set of policies — perhaps addressing access controls which prevent the downloading of any unauthorized software — would be appropriate.

A well-known intellectual property attorney recently mused about writing information security policies in a conversation with the author, saying: “The law doesn’t require that you be perfect, only that you’re taking prudent steps, and clearly making demonstrable progress.” To have a schedule for the release of various policies, with dates, and scope statements, and titles — that type of documentation can indicate that your organization is addressing what needs to be addressed, that it has a plan, and that it is making progress. In that respect, this plan for policies can at least partially document management’s due diligence process in the information security area.

Short & Modular: If the organization in question is very small, perhaps a startup cloud service provider with a handful of employees, then for a while, they can get away with a single document. But soon they will need to break their information security policy document into a series of segments. Larger and more complex organizations will find that short, modular, and tightly focused policy statements are easier to index, search, and update. Short and modular policy statements are also ideal for easy insertion into pop-up help screens, application system user manuals, and other system-resident text that is relevant to a specific task.

The title of, scope of, topics covered by, and scheduled delivery date of policy statements is additionally a function of the delivery systems to be employed. If more than one major delivery system is to be employed, the same ideas may need to be expressed in very different ways, compatible with the delivery systems involved. For example, if policy statements are slated to be delivered by broadcasters on a periodic management satellite-broadcast TV show, to a worldwide network of sales offices, and if the recipients are non-technical, typically impatient, and not particularly motivated to pay attention, then very short abbreviated verbal policies would be appropriate. But if policy statements will be delivered via an intranet, and users will have a wide variety of automated tools at their disposal, such as key word search utilities, then a longer more literate text-oriented style can be, and probably should be used.

Know your Audience: The way in which policy statements should be scoped, and hopefully modularized into bite-sized pieces, is also a function of the audience to be receiving the information contained therein. Policy writers should define who the major audience members are. Three favorites of this author are: end-users, technical information systems staff, and management. Another example of audiences, for an Internet merchant, would be: customers, third party business partners, in-house technical staff, in-house marketing staff, and top management. Still another example for a multinational manufacturing firm would be: staff in countries where there are operations, headquarters staff, and IT staff (both in-house and outsourced).

Of course there will be some redundancy of the messages delivered across these audiences, but it is important for the policy writer to define, in advance of writing policies, just what messages need to go to which audiences. After these messages and recipients are defined, the policies will often — of their own accord — naturally fall into certain categories, and these categories can then be used as a guide to segment the policy statements into different documents.

Start with the Essentials: So for now, concentrate only on what’s essential, but map out how all the rest of the policies will be structured, what they will entail, when they will be delivered, and who will receive them. See the big picture now, but don’t issue too many policies all at once. The ability of users to metabolize information security policies is surprisingly limited. Care and feeding requires well-thought-out, bite-sized pieces that are well tailored to the needs of the organization, and clearly viewed as essential at the time they are published. A steady diet of this type of policy will gradually raise the awareness level of the audiences receiving the material. Overfeeding will result in indigestion and push-back, and the recipients will then be unwilling to receive more policy material for a considerable period of time.

So the answer to the question “one or several policies?” should almost always be: “never just one policy, and not just several policies either, but instead a regular stream of tasty interesting policy vignettes.” These policy vignettes should be supported by examples, delivered only to relevant recipients as required, and consist only of information that the recipients absolutely must have now in order to maintain good information security. If the policy writer consistently uses this approach, he or she will see that the recipient appetite for more remains strong, and the credibility attached to each policy vignette likewise remains high.

——-

Charles Cresson Wood, MBA, MSE, CISA, CISM, CISSP, is an independent technology risk management consultant with InfoSecurity Infrastructure, Inc., in Mendocino, California. In the field since 1979, he is the author of a collection of ready-to-go information security policies entitled Information Security Policies Made Easy. His latest book is entitled Kicking The Gasoline & Petro-Diesel Habit: A Business Manager’s Blueprint For Action (see www.kickingthegasoline.com). He can be reached via www.infosecurityinfrastructure.com.

Continue reading »]]> In July 2011, The Australian Defence Signals Directorate (DSD) published an updated list of their Top 35 Mitigation Strategies. This list was based on the analysis of real-world events within the government agencies, and is designed to identify the top set of controls that would have the most impact on reducing actual incidents. The list contains 35 specific controls, with 12 listed as “excellent” at reducing risk and a clear “top 4″ controls that could provide the greatest benefit. According to the report:

While no single strategy can prevent this type of malicious activity, the effectiveness of implementing the top four strategies remains unchanged. Implemented as a package, these strategies would have prevented at least 70% of the intrusions that DSD analyzed and responded to in 2009, and at least 85% of the intrusions responded to in 2010.

Information Security Policy Solutions

While these lists are truly valuable, organizations must realize that implementing these controls must be done within the larger context of the information security program.Before being implemented, these controls must (1) also be documented in written security policies and (2) implemented as part of a comprehensive information security program. So while it might be attractive to think that just four controls can mitigate 70% of the vulnerabilities, the reality is that most of these controls require a series of supporting security policies.

Below are the top 4 recommended controls, including some comments regarding security policy support from Information Shield and their placement within the ISO 27002 standard.

1. Patch applications e.g. PDF viewer, Flash Player, Microsoft Office and Java. Patch or mitigate within two days for high risk vulnerabilities. Use the latest version of applications.

Policy Solution: These security policy controls are in the category of both patch management and acceptable use of assets (ISO 7.1.3) , since the controls are referring to software on user devices. Information Security Policies Made Easy addresses this specific requirement, as well as providing 25 other sample security policies relating to the control of end-user devices.

2. Patch operating system vulnerabilities. Patch or mitigate within two days for high risk vulnerabilities. Use the latest operating system version.

Policy Solution: These security policy controls are in the category of vulnerability management (12.6.1 Control of Technical Vulnerabilities) and patch management . To be effective, these policies need to incorporate both change management (ISO 10.1.2 Change Management) and separation of duties (ISO 10.1.3 Segregation of Duties) to mitigate other common insider risks. The PolicyShield Security Policy Subscription provides policy templates to address this specific requirement as well as 50 additional supporting security policies.

3. Minimise the number of users with domain or local administrative privileges. Such users should use a separate unprivileged account for email and web browsing.

Policy Solution: These security policy controls fall into the category of account and privilege management (11.2.2 Privilege management). PolicyShield provides over 100 separate security policy samples dealing this specific requirement, as well supporting security policies for system management and logging of privileged commands.

4. Application whitelisting to help prevent malicious software and other unapproved programs from running e.g. by using Microsoft Software Restriction Policies or AppLocker.

Policy Solution: These security policies are part of a series of controls for controlling malicious software (ISO 10.4 Protection against malicious and mobile code) and for configuration management of end-user systems (ISO 10.1.2). PolicyShield provides a set of 50 separate sample information security policies within these categories.

Conclusion

Any prioritized list of controls is excellent for prioritizing information security efforts an the organization. However, as these reports often point out, these must be implemented together as part of a “defense in depth” program. While considering these controls, it is also important to consider what other controls must be in place to help effectively mitigate the “top 4″ without introducing other risks.

Information Shield provides a library of over 2000 sample information security policies designed to implement a comprehensive, documented information security program.

Continue reading »]]> Laws & Regulations: This post is for organizations that could use help raising the level of management awareness and support for information security policies. From the get-go, let’s be clear that this post is not for established organizations that are already far along when it comes to their information security efforts. They will have long ago sold management on the importance of, and in fact, on the critical nature of, information security policies. But small and mid-sized organizations, especially newly formed ones, often don’t yet have information security policies, nor does management in those organizations necessarily consider policies to be a priority. The first hurdle to jump over with top management involves the erroneous notion that information security policies are optional. Perhaps that was the case in certain industries back in 1980. But that’s unquestionably no longer the case. So it’s up to us technologists to show top management what they’re required to do when it comes to information security policies. Reflecting this “no question about it” status, in many situations, written security policies are now required by laws and regulations. For example, if your organization is a financial services firm in the USA, then the Gramm-Leach-Bliley Act (GLBA) requires it to have a privacy policy.

So, if you have not already done so, this is a good opportunity to speak with your organization’s lead attorney about information security. In that conversation, see if you can identify all the laws and regulations that your organization must comply with, the ones that mandate certain information security measures. Many of these laws and regulations will require policies, deeming them to be as one of the most fundamental information security control measures that an organization can adopt. This author suggests a spreadsheet as a quick-and-dirty way to organize the investigation. Some vendors also sell ready-to-go templates that give you a quick overview of the relevant laws and regulations. But even if you buy these templates, nonetheless be sure to have a conversation with the lead attorney, just to make sure that all the bases are covered.

So, let’s assume that there’s no law or regulation in your country that requires organizations in your industry to have an information security policy. What do you do then? Or what if there is a law or regulation that applies to your organization, which requires a policy statement, but top management at your organization still believes that it’s unimportant to have an up-to-date information security policy? What next in those situations?

Standard Of Due Care: The next conversation that you need to have with top management has to do with the legal notion of the standard of due care. Mind you, this author is not an attorney, so to prepare for your top management meeting, you should once again go back and see the lead attorney at your organization. In this attorney meeting, you should discuss the principles of liability, specifically what would make management liable for not having adequate information security measures. You should also attempt to define the information security related standard of due care for your organization, in your country, at this point in time. The standard of due care defines what a prudent manager is expected do, at a minimum, or from another vantage point, what is legally required of all well-managed organizations.

Beyond statutory laws and regulations, there are a number of ways to go about illuminating the standard of due care, and all of these should be pursued, with the hope that at least one of them will end up being convincing to management. You can for example reference case law, which unfortunately is not as well developed as many of us would like (the dearth of case law reflects the fact that information security is still a relatively embryonic field). By the way, one of the classic cases in this area is T. J. Hooper v. Northern Barge. On a similar note, regulatory agency guidelines or policies may make a point of requiring information security policies at the organizations they regulate.

Well-known international information security standards, such as ISO 27001, are also a good reflection of what’s generally accepted, and what goes into the prevailing standard of due care. Policies are for example a key part of the “information security management system” defined in ISO 27001. A few highly respected books, used as references by practitioners in the field of information security, can also serve as an authoritative source of information defining the standard of due care. In this category we will for instance find the Information Security Management Handbook, edited by Hal Tipton and Micki Krause (Sixth Edition, 2009). This book likewise defines policies as an essential part of every information security management effort. Published legal books, which address the requirements for information security also fit into this category. In the latter group we find Readings & Cases In Information Security: Law & Ethics by Michael Whitman and Herbert Mattford (2010). Again, security policies are highlighted as essential.

Your organization may also have an industry association that writes information security related technical standards. For example, the American Banker’s Association publishes a great deal of material dealing with information security. In one of their sponsored webinars, for example, well-known information security consultant Peter Browne spoke to the Foundations Of Information Security. Information security policies showed up there as a key ingredient to a successful information security effort. Likewise, if government agencies have issued books or pamphlets about information security, these too will often cite the need for information security policies. For example, the Federal Deposit Insurance Corporation (FDIC) in 2002 gave a presentation about e-Banking Information Security Guidelines, and that too cited the need for written policies.

Professional associations in the information security field, such as the Information Systems Audit & Control Association (ISACA), have also issued relevant publications such as COBIT: The IT Governance Framework (use Version 5, 2010). This highly respected reference again makes the case why information security policies are an essential component of all successful information security efforts. There are other definitive sources you could consult, such as a list of security requirements that all organizations must have in order to join a multi-organizational business network. Dig around, and you will often find that information security policies are a requirement for joining such automated business networks. Keep going with the reference gathering effort, because sometimes management will only be convinced when a long list of these references is presented to them.

Role Of Security Policies: While it is beyond the scope of this posting to go into the many and varied roles to be played by information security policies (see for example the post entitled “The Security Policy Hierarchy: A Governing Policy & Subsidiary Policies”), it is important that management understand how critical information security policies are. For example, they need to know how policies are at the apex of a pyramid of documents that guide and focus internal efforts. They need to know how policies can help save their neck when there is an allegation of unfair treatment after someone was fired because they violated a security-related rule. So make a long list of how policies support and buttress information security work, and show how policies are on the critical path to moving ahead with many other related efforts. For example, if policies have not yet been written, it will be very hard for management to successfully negotiate an information systems outsourcing contract with a third party service provider, because written policies will need to be incorporated into the agreement with an outsourcing firm.

Risk assessment: While there are other ways to convince management to support and fund an information security policy development effort — ways that go beyond the amount of space available in this post — this author will just mention one more approach. This involves performing an internal risk assessment, where all the major risks and vulnerabilities are examined. By performing such a risk assessment, top management obtains a clear snapshot of what the story is, right now. If policies have not yet been prepared, no doubt that fact will be highlighted in the risk assessment. You can then embellish on the findings of the risk assessment, by writing a memo about what would happen if policies are not promptly written and disseminated via awareness raising efforts. Both of these documents put management “on notice” (a legal term), where they are now in receipt of a report about a serious problem, and they need to do something about it. Doing something might be deciding that they aren’t going to do anything, but that’s still a decision. You have put them on the spot now, and they can’t ignore the matter any longer. You have gotten it in writing so that there’s no dispute about it, if (heaven forbid), you should ever be up there on the witness stand. You have passed the buck, and management should be uncomfortable about that, that is until they move ahead with the policy development and dissemination effort.

Still Required: In 2011, it’s surprising that there are still many organizations that don’t have an information security policy that is both responsive to their current situation and up-to-date. With all that we know about information security risks, this should be a no-brainer. Hopefully staff at these organizations will soon convince top management to support and fund an information security policy development, dissemination, and implementation effort.

——-

Charles Cresson Wood, MBA, MSE, CISA, CISM, CISSP, is an independent technology risk management consultant with InfoSecurity Infrastructure, Inc., in Mendocino, California. His latest book is entitled Kicking The Gasoline & Petro-Diesel Habit: A Business Manager’s Blueprint For Action (see www.kickingthegasoline.com). He can be reached via www.infosecurityinfrastructure.com.

Continue reading »]]> Divergent Directions: Looking back over the last 30+ years of my work in information security, I see two diverging trends when it comes to defining the information security-related standard of due care. By the “standard of due care,” in this column I mean the actions that management needs to take (for instance the controls that need to be deployed), in order to avoid legal problems such as charges of negligence.

The first of these two directions involves the definition of a set of controls that all organizations should subscribe to, across the board. Examples include the ISO 27002 information security standard or the recommended controls from NIST SP800-53. The components of this set are for the most part already defined, but the size of the set is still expanding slowly over time. The second of these directions involves situation-specific requirements. The components in this set are for the most part still being defined, and the size of this set is rapidly expanding over time. In the long run, most information security requirements will be situation-specific requirements. This is so because the information security measures expected in banking would not necessarily also be expected in manufacturing (more about this below).

Management is not at liberty to choose one or the other set of requirements. Instead, in the future, they will be expected to meet both sets of requirements. This column explores some examples of the emergent situation-specific standards of due care, which of course should be expressed in an information security policy.

Evolving Legal Requirements: Unfortunately, decades of experience has proven that many top managers won’t spend money on, or devote significant attention to information security — unless they are forced to do so. I won’t name names, although it would be easy to do so. Top management at many large and reputable organizations has been taking an amazingly lax attitude about information security. For example, a few years ago, a large French bank was hit by a $4.9 billion computer-assisted fraud perpetrated by a rogue trader. In an effort to prevent these amazingly large losses, a variety of new information-security-related laws have been passed. For example, the Sarbanes-Oxley Act of 2002 (aka SOX) and the Federal Information Security Management Act (FISMA) both mandate a higher level of organizational vigilance, as well as a higher level of management accountability for information security. These laws are an example of the first category of requirements defining an across-the-board standard of due care. There are many others that could have been mentioned here, but this column is focused on the second category of requirements.

Besides the new laws and regulations, case law is defining the ways that the Board of Directors and top management must be involved with information security matters. For example, the 1996 Caremark International case establishes that directors have a duty to monitor compliance programs related to information security, to make sure that controls are operating as they should be. In that case, directors were held liable because they “should have known” that Caremark staff were violating Federal anti-kickback laws. Likewise, the 2003 Walt Disney case further clarified this standard of oversight that directors must exercise. In that case, the directors allowed the CEO to walk away with a $140 million golden parachute deal, even though he had been working on the job less than a year. Again, the directors “should have known” that these things were going on. The court decided that the directors did not act in good faith, that they had a conscious disregard for matters to which they should have paid attention.

Risks Define Policies: The information security risks facing a bank are really quite different from the risks facing a manufacturing firm. The former is very concerned about fraud and privacy, whereas the latter is very concerned about business interruption and quality control problems. Yet, because the information security field is still in such a young state, most firms are being subjected to a “one size fits all” approach. Granted, certain fundamental management duties associated with the information security function (sometimes called a “baseline”) can be defined across all firms. One function that goes into such a baseline is the performance of a regular risk assessment. In fact, ISO 27001 has defined such a baseline applicable to all organizations. But when it comes to the specific controls to be adopted, that conversation will often take us in a very different direction because controls must be a function of the risks, and the risks will be different from organization to organization.

Robert Courtney used to be head of information security for IBM. In a discussion with him years ago, he said, “you cannot determine whether a specific system is secure if you look only at the technology.” What he meant by that was that we, the assessors of the level of information security, must take the whole situation into consideration, not just the technology. For example, we must ask: “what are the business risks, the legal risks, the financial risks, and the other circumstantial factors in this particular environment?” Only when these factors are collectively considered can an assessor give any sort of a meaningful opinion about the prevailing level of security.

This situation-specific viewpoint is manifest in a host of new computing-environment-specific standards that are cropping up. Consider the Trusted Cloud Initiative. This new standard defines what controls cloud service providers should be providing to their customers. It focuses on the nature of the relationship between customers and cloud service providers, notably the need for transparency, so that customers can understand what cloud service providers are doing. The Trusted Cloud Initiative also focuses on the integration of security systems between customers and providers, for instance in the identity and access management area. Thus this set of information security requirements is largely defined by the nature of the outsourcing relationship and the new technology that goes along with that relationship.

The situation-specific viewpoint is furthermore manifest in requirements that define the controls relevant to a specific type of information. For example the Payment Card Industry – Data Security Standard (PCI-DSS) defines the controls that merchants — and also third-party transaction processors who are handling credit card data — must deploy. Among other things, PCI-DSS discusses how encryption must be used in order to protect credit card data. Here we see that the nature of the information involved (valuable, critical, and/or sensitive) defines the controls that should be deployed.

The situation-specific definition of controls is additionally now evident in a number of high-risk environments. For instance, about a decade ago, a handbook called OCC 99-9 was released by the Office of the Comptroller of the Currency (OCC). This handbook defined how banks should be handling information security. This handbook goes into a number off specific controls, such as what unauthorized attempts should be reported to the Federal Bureau of Investigation. In a similar way, the Gramm Leach Bliley Act (GLBA) also defines specific information security requirements for financial institutions. These requirements include an information security plan and policies detailing the ways that financial institutions are going to protect restricted-access personal information. Here we see situation-specific controls defined on an industry-by-industry basis.

The Best Approach: The military provides us with a phrase which defines the best approach to defining the standard of due care, as it will be observed within a specific organization. That phrase is “system high.” In the military, those words mean that the level of security is a function of the most sensitive piece of information resident on a certain system or network. For example, if the most sensitive type of information is only “confidential,” then the whole system or network must operate with confidential security measures. But if a new piece of information comes onto that system or network, and it is “top secret,” then the security on this system or network must be upgraded, so that it will then be operating according to a more stringent standard.

The system high approach can, and in many instances should be, applied to the definition of an organization-specific standard of due care. Your organization will find that it is subject to information security requirements defined by different entities such as government regulators (at different levels of government), courts issuing case law in the contract and tort areas, industry associations, and information security community groups. The system high approach dictates that all those relevant requirements be combined in a patchwork way, so that the most stringent of these then collectively make up the baseline, the minimum standard to which your organization should subscribe. This baseline would of course be explained in your information security policy document, and (if yours is a larger organization) probably an information security architecture document as well.

Part of the reason why we must go with the most stringent of the requirements is that there is not a direct match-up between legal and regulatory jurisdictions on one hand, and the scope and breadth of organizational or multi-organizational networks and operations on the other hand. For example, the requirements defined in European data protection laws are not found in many non-European countries. At the same time, multinational business operations are generally not restricted only to western European countries with these privacy laws.

To assure continued business operations without the need for special silos or separate collections of data, and without special content filters or walls to block the exchange of data, your organization should go with the system high approach. Yes, this will initially cost more, but in the long run it will probably not cost as much as you might at first blush believe. This approach brings many benefits, such as reducing costs because: (1) organizational-wide vendor discounts are obtained, (2) staff needs to be trained in fewer approaches to security, and (3) the computing environment is thereby simplified and standardized.

Legal Collaboration: To come up with an approach that makes sense for your organization, this author recommends that you discuss the matter with your organization’s attorney early in the development process, not just later on after you’ve got a specific proposal. If you collaborate in this way, the law can be used as a compelling force driving greater top management engagement with information security, and also clearly defining the information security related situation-specific standard of due care.

—————————————————————————————————————————

Charles Cresson Wood, MBA, MSE, CISA, CISM, CISSP, is an independent technology risk management consultant with InfoSecurity Infrastructure, Inc., in Mendocino, California. In the field since 1979, he is the author of a collection of ready-to-go information security policies entitled Information Security Policies Made Easy. His latest book is entitled Kicking The Gasoline & Petro-Diesel Habit: A Business Manager’s Blueprint For Action. He can be reached via www.infosecurityinfrastructure.com.