shopping cartShop
Call Us: 888 641 0500

The Shared Password Strikes Again!

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 …

Continue reading »

View full post

Security Policies to Address Internal Threat

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 …

Continue reading »

View full post

Security Policies to implement the DSD Top 35

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 …

Continue reading »

View full post

Security Policies to Address Internal Threat

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 …

Continue reading »

View full post

One Security Policy Document Or A Series Of Documents?

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, …

Continue reading »

View full post
The Shared Password Strikes Again! Security Policies to Address Internal Threat Security Policies to implement the DSD Top 35 Security Policies to Address Internal Threat One Security Policy Document Or A Series Of Documents?

Jul
08

Implied Security Policies Create Added Risk

by

The US Supreme Court has overturned a lower-court ruling and concluded that management has a right to review employee text messages on company-issued devices.  If used as a precedent, this case may have far-reaching consequences for employee expectations of privacy in workplace communications.  However, the ruling should also serve as a wake-up call for organizations that do not have explicit written security and privacy policies.

The case stemmed from an incident (reported here) where management at the Ontario Police Department reviewed text messages to investigate compliance with bandwidth usage policies on company-issued devices.  The department had an informal policy that limited usage to a fixed amount each month.  Once several employees began exceeding these limits on a regular basis, management began a review and in the process discovered that some people were sending personal messages containing explicit sexual content.  Once sanctioned, the employees sued the department claiming that their privacy had been violated.

Written or Implied Security Policies

A key issue in the case is that the Ontario Police Department, while it did have a written Acceptable Use Policy, it did not cover the monitoring of text messages.  Instead, there was an “implied” policy that employee messages would not be audited if they paid for their text message overage out of their own pockets.  This was enough to enable the 9th U.S. Circuit Court of Appeals in San Francisco to rule that the informal policy was enough to give the officers a “reasonable expectation of privacy” in their text messages and establish that their constitutional rights had been violated.

The Supreme Court overturned this ruling, sending a clear message that organizations have a reasonable right to inspect employee communications while attempting to assess compliance with corporate policies.

The Good News

This ruling confirms a common security policy in place today in many organizations – namely that employees should not expect privacy when using company-issued equipment.  However, the fact that this case went all the way to the Supreme Court illustrates an important policy-related lesson for organizations.

The Policy Lesson

All security and privacy-related policies should be in written documents, not implied in any verbal or informal communication. In this case, having an “implied” policy, rather than a written one, set up a risky environment for the Ontario Police that landed them in the news and exposed their business at the highest levels.

Tags: , , ,

Leave comment

Aug
02

The Shared Password Strikes Again!

by

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.

Tags: , ,

Leave comment

Aug
02

Security Policies to Address Internal Threat

by

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.)

Tags: ,

Aug
02

Security Policies to implement the DSD Top 35

by

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.

Tags: ,

Jul
19

Security Policies to Address Internal Threat

by

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.)

Tags: , , ,

Jul
19

One Security Policy Document Or A Series Of Documents?

by

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.

Tags: , ,

Jul
13

Information Security Policy Whitepapers

by

Here is another link with the whitepapers and text.

Tags:

May
26

Selling Management On Information Security Policies

by

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.

Tags: , , , ,

Mar
25

The Shared Password Strikes Again!

by

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.

Tags: , ,

Mar
25

A Security Policy Standard of Due Care

by

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.

Tags: , , , ,

Feb
28

The Information Security Policy Hierarchy

by

Developing A Governing Policy & Subsidiary Policies

A Maturing Field: As the discipline of information security becomes more sophisticated, codified, standardized, and mature, it is not surprising that the old-fashioned approach to information security policy writing is no longer appropriate. We are talking here about the “one-size-fits-all” information security policy that is supposed to apply to all workers in a specific organization. Different people within an organization have different things that they need to know from an information security policy. This diverse set of readers should not be required to wade through a lot of irrelevant material in order to find the sought-after information.

More and more organizations are breaking their single information security policy document into various information security policies. What we often see is an umbrella information security policy relevant to all readers, accompanied by policies intended for specific readers only. In the latter category we see policies for systems developers, quality control engineers, and other functional groups. Most readers do not need to read the latter type of narrowly scoped policies, so it’s best if this information is separated from the main “everyone has to read this” material.

Getting User Friendly: After this separation between an umbrella policy and subsidiary policies, on a level of sophistication scale, the next stage is breaking down information security policies by job title. A very large American bank did this with great success via an intranet, and the workers really appreciated knowing what exactly they were responsible for, and also what they didn’t have to worry about. Using a more progressive perspective, it would be better to structure this document breakdown by specific cross-departmental business process. As information security policies continue to expand in size, and as they become ever more detailed, this type of audience targeting is increasingly necessary.

On one more sophisticated level still, a level to which very few organizations have presently gone, is a breakdown of policies into very brief statements relevant to a specific task. For example, if someone wanted to gain access to a new computerized business application, a privilege that they currently didn’t have, the organization could have built a series of web forms that such a person could fill out to submit a request. Pop-ups would appear instructing them as they fill out these forms. On selected pop-ups, and also available as links (to be followed as desired), they would see a paragraph or two of information security policy material, but only material relevant to this specific task. Unfortunately this approach takes a lot of effort, is rather time consuming, and in some instances can’t be done at all (if off-the-shelf packages are used for example). Nonetheless, this approach integrates information security with automated processes, and in that respect is desirable because it communicates the message that “information security is a normal part of how things are done around here.”

This last approach eliminates the whole question of people ignoring information security policies, for example because they failed to consult the policies that were found in a separate place. Instead the policies are merged with business processes, and compliance is achieved via one or more action-forcing mechanisms. An example might be a digital signature from a departmental manager being required before access to a specific system privilege is granted. A systems administrator would be blocked from changing the privileges for a normal end user unless that digital signature has first been obtained and confirmed as legitimate.

Long Term View: If one uses an umbrella information security policy, sometimes called a governing policy, and then develops specific policies that fall under that umbrella policy, you will find that maintenance and updates will be considerably easier. Approval of a short and narrowly-scoped document will be conceptually easier for many people, especially non-technical managers. Breaking things down in this way also supports making a clear and sharp distinction between different types of information security documentation, for instance distinguishing between policies, guidelines, procedures, technical standards, and contingency plans. Clearly differentiating between these document types allows information security policies to be kept on a high-level of abstraction, and thus at least potentially be in force for five years without modification (although policies should be reviewed annually for relevance and needed changes).

In an umbrella policy, we will typically see a statement of objectives for information security, which explains how these objectives support organizational goals. We would also typically see a statement from the CEO stating his or her expectation that everyone working at the organization comply with all information security requirements (policies being just one of these). We would additionally expect to see human resource related matters applicable to all readers. For example, a discussion of the disciplinary actions that will be taken in response to a violation would be found in an umbrella policy. Training and awareness matters, such as a required annual refresher course, those too would be addressed in an umbrella policy. Structures used in other policies, ways of looking at information security that everybody needs to understand, such as the user-custodian-owner model, these would also typically be explained in an umbrella policy.

Links to Specific Policies: In an umbrella policy, we would furthermore expect to see links to more specific policies, sometimes called technical policies. These more specific policies could address generic areas like access control, user authentication, system logging, physical security for computers, and encryption. Although some organizations have chosen to organize their more specific policies along the lines of vendor technologies, like the Windows operating system, this author recommends against such an approach. Information is not confined to only one operating environment, and a consistent approach to security is needed across all vendor technologies, across all operating systems, and for that matter across all organizations that have access to the information in question. It is far better to take an information sensitivity oriented approach, for example breaking statements about required controls down by a data classification system. This approach reflects the perspective that technology should follow business needs, and of course information security is a business need.

So when structuring the subsidiary policies, you can use the traditional role-based approach, you can use a business process based approach, you can use an information sensitivity based approach, or you can use an issue based approach. With the latter approach, in one subsidiary policy document, we would for example talk about what to do after there has been an intrusion. That document would address who makes executive decisions such as shutting the affected system down, what information abut the intrusion must to be recorded for legal and insurance purposes, how to gather and properly store evidence, who acts as a public spokesperson, etc.

Subsidiary Components: More specific subsidiary policies should for example address matters such as: (a) who is responsible for buying, renting or leasing new systems, (b) who must approve of the security measures on new production systems, (c) who is responsible for managing the security on these systems, and (d) how these systems must comply with standardized configurations. The operating system configurations can and should be defined in separate documents, for example a set-up procedure for systems administrators. In general, if a separate person is going to handle the more detailed matters, such as configuring a new computer, then this is a good point at which to have a separate document.

Using this — or a similar — rigorous top-down hierarchical approach will bring a discipline to information security policy writing that will be much appreciated down the road. This author has seen far too many cases of spaghetti-style policy writing, where everything is hopelessly interconnecting and overlapping, and it’s very hard to figure out what the policies actually require. Of course, in the latter case, update and maintenance is a nightmare. Often, the lowest-cost and most-expedient approach is to replace the whole spaghetti-style document with an entirely new set of clearly-structured documents.

A Bonus: Another significant benefit of breaking things down as suggested here is that access control, based on the principle of “least privilege” can easily be maintained. For example, if a contractor is going to help with the systems design of the accounts receivable system, then only the security policies applicable to the accounts receivable and collections areas need to be disclosed to him. And for many other people too, both inside and outside an organization, both separation of duties and dual control can be better supported if we have a combination of multiple narrowly-scoped policy documents, and access control restrictions at the document level.

Whatever your reasons for structuring information security policies the way you do, make sure they reflect the business needs of the organization in question. More specifically, before you make a decision about the appropriate policy document structure, make sure your organization has a recent risk assessment that talks about the most pressing information security issues confronting the organization. It’s important to use that information to then create a structure for policy documents that fits the prevailing organizational structure, vulnerable business processes, and important information security tasks.

Tags: , , , ,

Older posts «