Compliance « SecureThinking

Posts tagged Compliance

Tuesday, July 20, 2010

CISOs to the Rescue!

By Jill Knesek, Chief Security Officer, BT Global Services

There aren’t many times I check in on the trade publications and see an article that really hits on the issues faced by the C-level audience in the security sector. Frankly, we’re an unusual bunch, with very specific interests, issues, and concerns. But recently, I saw an article by Ernie Hayden at searchsecurity.com that got to the heart of some of the compliance issues that I know I face and I’m sure you grapple with, too.

Approaching compliance from the standpoint of managing processes, Hayden outlines five key propositions that can help guide decision-making and apply as equally to PCI as to NERC. His top picks are:

Your fundamental obligation to the company is to protect data and prevent loss
You should know the ins and outs of the regulations your organization is held to
View training and awareness as key components of your compliance strategy
Understand the root cause of any issues related to compliance
The organization should be kept under constant pressure to be in compliance

To read Hayden’s entire article – “How to manage compliance as Chief Information Security Officer (CISO)” — click here.

And if you’re a C-level or senior security officer in the Chicago area and would like to continue this conversation over dinner, I’ll be hosting a BT Security Roundtable in Chicago on July 28. To learn more about the dinner, please contact our Chicago-area managed security solutions specialist, Kurt Luporini.

Thursday, June 17, 2010

Part 2: What is your risk appetite? Counting security calories won’t help

By Jim Tiller, Vice President, Security Professional Services, North America, BT Global Services

The term risk appetite is used frequently as a method to generally convey the level of criticality that must ultimately be interpreted, but rarely is this explored deeply. There is a great deal of effort in defining risk and creating models as opposed to providing equal or greater focus on defining appetite, which is arguably the tipping point that determines the overall value of risk management to the organization. The industry is so intensely focused on risk management theories and methods that it has virtually ignored the most important aspect – which is how the results will be digested.

For example, a risk report expresses several high, medium and low risk conditions. However, risk appetite governs which of those risks actually mean something to the company, group or person. A low risk could be of great importance to one group and cursory at best to another. Moreover, that condition may reverse in a short period due to business dynamics.

What I find interesting is risk acceptance — a formal confirmation from the business that the identified risk is absorbed. But rarely are risk acceptance forms reevaluated, much less done so on a timeline that is reflective of the criticality level of the identified risk – a factor which completely ignores the importance of appetite and change in appetite over time.

A risk appetite model needs to be developed that defines a process by which appetite can be quantified relative to business conditions and deeply incorporated into the risk management paradigm. Today, this mostly surfaces as evidence used in general discussion of appetite, such as policy statements and regulatory demands. However, these can be seen as surrogates for appetite.

For example, how an executive interprets risk (their appetite) is “trumped” by a regulation because there are tangible impacts, such as fines or going to jail. But not all risk results cleanly fit into these situations. What happens today is often less focus on broad risks and stronger focus on divisional risk so that the results can be interpreted by one person that makes the final judgment call on appetite. This process essentially avoids the problem by reducing the number of people who need to “make the call” and isolate responsibility. In fact, this practice is typically the security group transferring political risk to a single person who actually makes a decision.

Security groups need to tackle risk appetite measurement as other industries have – specifically, the financial industry concerning risk appetite for investors, which is very interesting and has some meaningful formulas that could be used as the basis for security appetite measurement. There have been what I would call attempts in security, such as ISACA’s case study using CobiT to define risk appetite.

But as you can see, it’s still about measuring risk (i.e., high, medium, low), not necessarily specifically the interpretation of risk. In other security circles it has been suggested to use Myers-Briggs, which is a very interesting starting point. But others have suggested a litmus test using hypothetical scenarios to capture a perspective of risk relative to appetite.

While I agree with the concept, how the test is performed will determine the value of the data. If the test candidates know they are being tested, the results will be skewed – and I’m not too sure executives want to be treated as lab rats.

Nevertheless, the point is simple — today’s risk management practices are good, but they can be a lot better if appetite is seen as important as threat, vulnerability, likelihood, and impact. The good news is that people are thinking in these terms, but it has yet to take on legs.

If you are aware of any models in the works, please let me know.

For more on Jim’s thoughts on risk management and risk appetite, see Part 1: What is your risk appetite? Counting security calories won’t help

Tuesday, June 15, 2010

Part 1: What is your risk appetite? Counting security calories won’t help

By Jim Tiller, Vice President, Security Professional Services, North America, BT Global Services

Anyone who knows me or has subjected themselves to my writings knows I have some uneasiness with today’s role of risk. It’s not the process, but more of how there is so much focus on risk as if it were a science – but it’s not. Not even close.

Risk management is, of course, extraordinarily important to a security program, but I regularly see it positioned as “the” security program — with all things stemming from risk measurements as if it were an absolute. One of the things I hear a lot is “risk appetite,” and I’ve even used this phrase myself many, many times. But what is it?

Risk management is a tool that can help take in vast amounts of information and process it to a point where you can begin to make sense of it. From there, it can support decisions, actions and investments. Risk management boils down to finding a balance between threats and assets by the allocation and management of controls. That balance is ultimately based on risk appetite, or more specifically, the amount of risk you are willing to accept for a given potential event. And the level of risk appetite will inexorably govern the response, not necessarily only the level of risk measured.

Therefore, one could argue that risk management is not much more than an exercise without a quantified understanding of risk appetite.

Security risks are subjective and as such, they cannot be objectively rationalized or accurately measured. The problem is far too fluid and unbounded; there is imperfect knowledge with security risks, and, more importantly, they don’t present any actuarial data to derive any form of meaningful predictability. Although certain elements can be forecasted with some reasonableness to determine general impact from specific experience, there remains the framework of the formation of estimates and rankings. Therefore, not only is risk open to interpretation, but the very risk model chosen for evaluation will greatly impact the outcome. Risk – at best – is a guess.

I must state that this does not mean that risk management is completely pointless — far from it. In lieu of anything better and more accurate, today’s risk processes are what they are. However, risk must be used cautiously since there is significant room for error.

So what is appetite, really? In short, it is an opinion — and an opinion at a point in time. It is individualistic and mostly related to internalized (i.e., your own) risk philosophy. The oldest example used in discussions of this nature is the fear of flying, and a preference for driving as an alternative, when driving clearly represents substantially more risk. In other words, risk is very personal.

For example, if you say that there is a risk that could lead to an executive going to jail as opposed to something that represents far greater risk overall, the level of risk appetite will be far less with the former because it hits closer to home. Additionally, risk philosophy can apply to groups creating scenarios where each layer of the business will experience different levels of risk appetite for the same risk — and no two shall be the same.

Further exacerbating the issue is the interpretation of risk treatments. Even when there appears clear alignment between an identified risk and a security control, the interpreted effectiveness of the control will influence risk appetite a great deal.

Check back on this SecureThinking site later this week for Part 2 of this article, in which we’ll briefly cover gaining more visibility into risk appetite and emerging examples for measurement.

Wednesday, May 5, 2010

The States Take Action: Washington Becomes the 5th State to Give Data Privacy Some Legislative Teeth

By Sushila Nair, Product Manager, Managed Security Solutions Group, BT Global Services

In 2005, California’s Assembly Bill 1950 (AB 1950) became active, requiring a business that owns personal information about a California resident to “implement and maintain reasonable security procedures and practices to protect personal information from unauthorized access, destruction, use, modification or disclosure.” Since then, this law has been used as a basis for private and class action lawsuits and, it would seem, a model for other states’ legislation.

Similar legislation has been passed in other states, including Massachusetts, Minnesota, Nevada and, most recently, Washington state. HB 1149, which takes effect on July 1, 2010, provides issuing banks a legal mechanism to collect the costs to reissue payment cards after a payment card security breach. While there is no explicit requirement for organizations to take reasonable care to avoid a breach, companies that fail to do so may be liable to pay for re-issuance costs after a breach.

Of all these laws, the Massachusetts law is regarded as being the most comprehensive and, not surprisingly, implementation has been delayed many times; currently, the deadline for compliance to Mass. 201 CMR 17 has been extended to May 1. The law clearly calls for the need to discover and protect sensitive data in a manner that is absent from other laws that are being passed; but it no doubt will become a template for similar legislation elsewhere.

A federal law mandating security controls is missing, but it’s worth noting that in the case of a large scale security breach, the FTC has taken action by claiming that organizations have engaged in “unfair practices” in violation of Section 5(a) of the Federal Trade Commission Act, 15 U.S.C § 45(a). The FTC said it was unfair for the company, TJX, to collect private credit card information from consumers and fail to use adequate security procedures to protect it. TJX must obtain audits by independent third-party security professionals every other year for 20 years as a result of the FTC’s action. The definition of “adequate security” is, however, not clearly defined by the FTC, but it is fair to assume that PCI DSS forms a framework which can be used to measure an organization against.

With different states mandating various forms of security controls on storing sensitive information, organizations will obviously be required to comply with multiple sets of “reasonable security” requirements for each state where they have customers, a factor that will be confusing and expensive. The focus will center on one set of security controls and, love it or hate it, PCI DSS undoubtedly is being focused on as providing this framework.

What becomes an interesting part of this debate is whether or not this is the right direction for the United States to be taking for credit card security. Elsewhere in the world, the focus has been on increasing the security of credit cards by introducing smart cards and requiring secondary authentication for online banking. Half the world’s credit card transactions occur in the U.S., and while smart cards do not reduce card fraud, it’s a step in the right direction to introduce security into payment systems that were never really designed with security in mind.

As we struggle to get companies to introduce more effective controls around the storage and transmission of personal data, the question becomes — should we also be focusing on strengthening the processes that use that data to prevent it from being used without additional authentication. It is likely that banking regulators will revise their guidelines and start to issue stricter guidance, which in turn will prompt banks to offer better authentication mechanisms to protect consumers. But that needs to follow through to online merchants and the login behind credit card transactions — because let’s face it, the entire process seems to be quite broken.

Wednesday, March 24, 2010

Proven Security Practices for Smart Grid Security

Part #2 – Second in a Series on Smart Grids

By Jim Tiller, Vice President, Security Professional Services, North America, BT Global Services

In my last post, “Will the future of Smart Grids include smart security?,” I talked about the impact of the Smart Grid (SG) and asked if Smart Grid’s inventors’ have learned the lessons of the Internet age and built security into the technology from the start.

The fact is, if security is not in the fabric of SG technology, it could be highly disruptive to the core of our energy systems.

So what proven security practices can help ensure we’re moving in the right direction?

Vulnerability and penetration testing – Although SG is using many standardized technologies, there are some unique attributes in implementation that represent new forms of vulnerabilities. Everything needs to be tested on a regular basis — applications, protocols, infrastructure, firmware, and hardware all need to be reviewed for security flaws.
Security event monitoring – Today, monitoring information systems is typically associated with servers, security systems (e.g., firewalls, IDS, etc.), databases and applications. Not only must this be replicated in the SG environment, but must include embedded systems. This means vendors of SG products and solutions must incorporate the means to produce information relative to the operational nature of the devices so that we can gain visibility into potentially undesirable activities.
Application security – No security discussion is complete without discussing application security. Although akin to testing, application security is about sound development practices with security deeply ingrained in the development lifecycle. Today’s web-applications are complicated and sophisticated and, regrettably, complexity is often security’s nemesis, forcing developers to take a hard look at functionality versus stability. Although, there have been some advancements in secure SDLC, it is likely this will increase rapidly in the SG space.
Identity and access management – Having a mechanism to identify, authenticate and authorize users and systems interacting with the SG environment will be critical to its overall success. Just as much as you don’t want someone logging into your bank account, you don’t want unauthorized people interacting with how power is being delivered to your home.
Risk assessments and threat analysis – The introduction of information systems, especially when connected to the Internet, establish a broader threat profile. Risk management within the utility sector is far more complicated than in other industries because risk appetite is relative to a very broad community. It isn’t simply protecting the business, but protecting citizens and the sound delivery of an essential. Therefore, comprehensive risk assessment that includes an acute focus on threats will need too be performed regularly and through every step of implementation.
Security governance and standardization – Unlike Internet security regulations, like SOX and GLBA, which surfaced quickly to ensure consistency in the protection of public and private information — there are few security standards and requirements that vendors must follow in the design and implementation of SG, which can spell disaster. The silver lining here is that based on the Energy Independence and Security Act (EISA) of 2007, NIST has become far more involved in producing such materials, and making reasonable progress with the first Smart Grid Cyber Security Strategy and Requirements standard to be finalized in the spring of 2010. We should expect NIST to become the center point for security standards in this sector, thanks in part to the American Recovery and Reinvestment Act (ARRA) of 2009, which has clearly helped establish the organization as the source for standards behind developing regulation in the federal government and industry regulators, such as NERC.

As we have experienced with the Internet, what is done today for security during the embryonic stages of SG development will resonate for decades in ways we cannot fully appreciate right now. Those involved in the development and implementation of SG, from vendors and providers to the government and standards bodies, are aware of the importance of security and are working to create a solid foundation. However, there is still a lot more work that needs to be done and the best way forward is to learn from the past.

Friday, March 5, 2010

Past the Point of PCI

By: Sushila Nair, Product Manager, Managed Security Solutions Group,

BT MSSG &

Sanjay Mehta, Senior Vice President, Breach Security

The nirvana of that moment in time when you are completely secure without a single vulnerability in sight is unfeasible and, even if it were possible, it would be fleeting. Despite our fondest wishes for this moment, we accept the fact that our networks are vulnerable and are in a constant state of flux, causing the vulnerabilities to alter and the risks to change. Organizations struggle with how to continue to develop their core business while managing their risk and doing it all with fewer people and resources than they had last year. The only way this is possible is to work smarter – but how does that translate into practice?

We accept that our security is flawed, so it becomes critical that we place security devices wherever we have high or unacceptable risk. It is essential that the security alerts from security products like WAFS, firewalls, IDS/IPS as well as host information and application logs are centralized. The devices we select are critical and should be chosen in line with risk. It is worth bearing in mind that web applications are one of our largest areas of risk and were one of the key areas of focus in PCI DSS 1.2 which was based on the forensics of card breaches.

Once the devices are selected, then the complexity of managing this new technology comes into place and again, outsourcing is a serious option for companies that are constrained by head count. The footprints of what has happened on our network is in our log files, and it’s impossible to check the multitude of consoles for the vast array of product that we have, so it is critical we centralize our log files and have the capability to correlate and look for patterns of attacks. Unfortunately, security breaches are not limited to 9 to 5 or business hours, so our security monitoring framework must be built to take this intelligence, look for patterns of attacks and be manned 24×7.

This week’s RSA Conference pinpointed the problem of treating compliance as a single point in time.

Most companies breathe a sigh of relief once PCI compliance is “achieved” via an audit or code review. IT professionals move on to the next priority, and often, compliance “maintenance” is forgotten. In doing so, they fail to understand that audits and code reviews are outdated the moment they are completed. Web applications continue to be developed and altered, and as a result, continued compliance can’t be ensured with the “one-time look” that occurs with audits and code reviews. And it would certainly be cost-prohibitive to conduct an audit or review with each application change.

Fortunately, continuous PCI compliance can be achieved using a web application security solution that provides real-time, continuous security for all protected web applications.

In today’s compliance landscape, it’s simply not enough to know that a problem exists. Sophisticated web application security solutions help companies mitigate problems. Organizations need to have a real-time solution – not just a single look in time – to be truly secure and PCI compliant.

Here is more information on how vulnerability scans and code reviews compare to web application firewalls:

Vulnerability Scans and
Code Reviews

VS.

Web Application Firewalls

Looks at one web application at a single point in time.

Provides real-time, continuous security for all protected web applications.

Must be repeated for each application change.

Profiles each application’s acceptable behavior and automatically learns changes.

May not cover every line of code.

Secures the entire web application.

Can result in inconsistent findings due to vendor interpretations.

Provides factual information on vulnerabilities.

Does not fix vulnerabilities that are found.

Serves as a “virtual patch” that protects each application’s vulnerabilities.

Is expensive.

Offers immediate ROI.

Friday, February 12, 2010

Are you driving yourself insane with compliance?

By Pete Russo, Senior Marketing Manager, BT Global Services

Is compliance enough for your organization to be secure? BT’s Jason Stradley recently wrote in CSO magazine how companies confuse a completed compliance checklist with ironclad security. Interestingly, Stradley says, “… compliance is a poor excuse for security”:

Approaching this from the direction of building specific solutions or groups of solutions to answer each compliance requirement will ultimately lead to an overall security posture that is lacking basic elements and is inherently insecure. Such an approach may create a security function that is more reactionary than it was prior to having the regulatory compliance variable factored into the mix. This leads us to the undeniable realization that while a byproduct of security is compliance, the reverse couldn’t be further from the truth. Given that realization, hopefully we can all be somewhat in agreement that compliance is a poor excuse for security!

If you need evidence, look at the Heartland Payment Systems breach. This major breach has taught us that compliance alone is not enough to stop an attack. While Heartland was compliant with the PCI DSS requirements, the company still experienced the biggest breach ever involving payment card data.

Clearly, compliance is not enough. As more organizations accept this fact, we must look at how we can accomplish a comprehensive security program that is a strategic function of an organization. Here’s what Stradley recommended:

Develop a long term plan or “road map” for information security within your organization and include provisions for the known compliance requirements
Work closely with your senior business executives as you create this “road map,” so that they can understand where you are going, how it will affect their part of the operation, and it will give those business leaders an opportunity to provide you with better information to build it right the first time
Share the vision of your “road map” with your entire security organization and empower them as evangelists of that vision
To the extent that your are able, plan for potential future compliance requirements in your road map
Think of these potential new requirements as you build the various security capabilities within your organization. Try to build in the ability to adapt to new or more stringent compliance requirements without major upheavals to current processes, procedures and controls in place

By following these recommended steps, your security team will become less reactionary and more proactive. This will enable your security programs to become more valuable to your enterprise and a true strategic partner to the business.

Leave us a comment and let us know your thoughts.

Thursday, February 11, 2010

When is Good, Good Enough?

By Toby Weir-Jones, Vice President, Product Development, Managed Security Solutions Group, BT Global Services

Brian Krebs recently shared a familiar-sounding story with a new twist. Thieves, using valid credentials for PlainsCapital Bank’s online systems, initiated wire transfers from the account belonging to Hillary Machinery to international destinations. Instead of the victim suing the bank, the bank is preemptively suing the victim.

PlainsCapital is asking the District Court to certify that the bank’s security practices were commercially reasonable. The bank’s key argument is that no attack on its systems took place; valid credentials were used, and it processed the wire transfers in good faith. It therefore claims not to be at fault. The victim, conversely, suggests that the registration-email tool should have been smart enough to flag source IPs which weren’t assigned to the victim’s network, and therefore the bank is indeed guilty of using inadequate security controls.

This is a real-world example of an idea we blogged about shortly after CyberMonday 2009 — making costs of online activity visible to the end customer. The current status quo for attacks such as the one against Hillary generally result in the victim suing the bank, and the bank filing a claim against their insurance or otherwise paying out-of-pocket. PlainsCapital is saying, in essence, that the remaining $200k is the victim’s cost to bear, and the finger-pointing regarding who performed the correct (or inadequate) risk management is taken off the table. Hillary doesn’t need to enable online wire transfer services, the argument would go, and the choice to use it comes with an inherent cost. Now, unusually, we are attributing a real-world figure to that abstract cost notion.

Without knowing how the courts will handle this particular case, the key discussion is around whether a service provider online is covered against customer claims if they have employed commercially reasonable controls for that service. For example, it is no longer adequate simply to say you offer “authentication”; but the costs of managing a large number of tokens is still prohibitive for most systems, and the average customer will not pay an additional fee for the benefits of a third factor. The industry has offered up a variety of soft tokens in response, and for systems protecting personal financial or credit information, this would seem to be a fair minimum standard of protection. Customers should also demand some kind of reputable third-party validation on the quality of the implementation, since good controls are worthless if they are poorly setup. An opportunity exists for a rating scheme which is both technically sophisticated and consumer-friendly.

In addition, customers should require some kind of disclosure about extranet, WAN, and other third-party connections between their primary vendor (online bank, insurance broker, mortgage company, etc.) and any other parties in the supply chain. Obviously the same standards used for the vendor’s in-house infrastructure should be required to be met or exceeded by those third parties as well. Banks (and compliance officers) will cringe at the complexities of performing annual audits to certify to this extent, but that is due primarily to cost objections required to do it properly. If a vendor can’t make it work, it’s probably an indication of inadequate executive-level support as much as it might be too revealing about the poor state of the infrastructure.

So the strategy appears to have two steps: first, ensure you really do employ commercially reasonable (“best”) practices, and second, defend them proactively in court by seeking a legal opinion to validate they are robust. The current mechanism of case law precedent won’t move fast enough to keep up with evolving best practices, but if a few courts do indeed issue judgments that it’s legally possible for a court to take the question of inadequacy off the table, the circumstances may create an unfortunate situation in which the courts are providing an opinion that was previously the domain of specialized assessment engagements and bleeding-edge specialists.

It’s not clear whether that’s better than having dueling experts fight one another in cross-examination, but I think most would agree that the court is unlikely to possess sufficient knowledge to evaluate corner cases reliably. We therefore end up in a classic conundrum: how to define the application of best practices with sufficient precision that you remove much of the interpretive spin of the exercise. Vendors providing such assessments or opinions should be working with legal counsel to ensure the findings are both technically and legally unambiguous, framed in specific, tangible terms, and honest about the boundaries of coverage or testing exposure. The audience, after all, may not be limited to internal technical company personnel, and the findings should be understandable to someone with a broader point of view.

Tuesday, February 2, 2010

Ranum and Schneier Discuss Compliance and Social Network Security

By Pete Russo, Senior Marketing Manager, BT Global Services

By now we’re pretty familiar with the face-off debates between Marcus Ranum and Bruce Schneier, chief security technology officer, BT. Usually they’re being asked about the BIG security questions, like the future of the security industry and will it exist in five or 10 years’ time. But, at the Information Security Decisions Conference in October, they got into slightly more down-to-earth territory with discussions about whether compliance mandates enhance security or are simply part of the on-going theater — and whether social networks at work are a dangerous security mistake.

In keeping with his writings on the generation gap in thinking about security, Bruce is not as skeptical as you might think about the integration of secure social networking into business. In his opinion, social networks in business are inevitable, just as security mistakes will be – so we need to take the plunge and get started on the learning curve.

On compliance, Bruce is more skeptical about whether industry and government mandates are ushering in good security practices, but at least they are forcing companies to buy security products and services in order to meet requirements. In other words, compliance is good for security, if only by accident.

To view the entire Ranum-Schneier talk, click here.

Tuesday, December 29, 2009

Meeting of the security minds in NY

Peter Verderber, Principal Consultant, BT Global Services, CISSP, CISA, QSA

At this year’s BT Managed Security Leaders Conference in New York, I had the opportunity to speak on a topic that has caused heartache for so many security leaders across a number of organizations — the notion that achieving a state of compliance means that an organization can be considered secure.

What was evident throughout the discussion is that I was speaking to the choir. Our customers who participated in the conference are acutely aware this notion does not hold true. However, it was also clear there are still challenges in shifting this perception at the executive level, especially when it comes to obtaining funding.

In advancing sound practices within organizations, security leaders have used “compliance” as a way to fund security initiatives. While the compliance mandate has been a huge driver for security in many organizations and has generated some valuable funding, it has created momentum behind a reactive approach and is leading down an unsustainable path. Security leaders must continue to be persistent in getting executive management onboard with understanding how an effective, business-aligned security program will be better positioned to simply absorb the next compliance mandate without the need for ongoing funding requests in the name of “compliance.”

The era of legislation has only just begun, and organizations that bring their security program in alignment with the business will be more agile and gain significant efficiencies in responding to new and evolving regulatory compliance mandates.

Jason Stradley, a BT senior security consultant, wrote in a recent CSO Magazine article that “compliance as security” is “the root of insanity” — and I couldn’t agree more. The overwhelming market focus on compliance is an unfortunate distraction for many up the food chain. Security leaders are plagued with continually needing to translate this mass-media message to the inherent security challenges that are being addressed within the context of the business. As arduous and repetitive as this translation may be over time, I encourage security leaders to continue to proactively set the course for their security program rather than just focus on satisfying regulatory mandates. In the end, this proactive approach, with focus on enabling the business, will demonstrate the true value of an effective security program.

What lies ahead in a world of ever-increasing regulation will be more opportunity for security leaders to engage with executive management to elevate the conversation on business-aligned security, clearly demonstrating how, over the long-term, security driven compliance is the way to go!