J Wolfgang Goerlich's thoughts on Information Security
Risk management circa 2018

By wolfgang. 5 December 2013 18:11

This past Tuesday, I was out at Eastern Michigan University speaking with information assurance students. The prof invited me to visit his Risk-Vulnerability Analysis class and asked that I give my Practical Risk Management talk.

Practical Risk Management was a talk I had given widely in 2007-2008, describing my efforts to stand up a risk management practice for a financial services firm. The case study covers aspects that I found went surprisingly well, and aspects that I found were surprisingly hard. Since five or six years had passed, I had expected to have to significantly revise the slide deck. Clearly, lots has changed, right?

Surprisingly, no.

The areas we wrestled with last decade remain challenging for clients and organizations today. I found little had changed. On the bright side, that fact simplified my revisions to the slide deck for Eastern Michigan University. On the down side, of course, that means we continue to struggle.

Why? In part, it is because of the seductive simplicity of the Risk = Asset * Vulnerability * Threat formula. Find the values, plug them in, multiply, and prioritize. Easy, right?

Easy, except asset management and valuation is tricky. Few organizations have a reliable hardware and software inventory. Fewer still have automated audits and the ability to see, immediately, when the inventory changes. This matters as such changes are often an indicator of compromise. Few organizations, too, can tie assets to business processes and provide financial valuation on impact. The question of what we have and why it matters is elusive.

And vulnerability management? Putting the dependency on an accurate asset inventory aside, vulnerability management is not quite a slam dunk either. True, software such as Qualys takes the grunt work out of the process. Automation can also shift from annual assessments to continuous vulnerability assessments. Yet the real difficulty in vulnerability management continues to be driving the remediation efforts. Thus we see many vulnerability management programs with tens of thousands of open vulnerabilities.

Threat management has made some progress. In 2008, my chief concern was a lack of threat intelligence and information on what actual attackers were using to achieve actual objectives. Today, we have better information sharing (ISACs, CERTs). We also have services like Risk I/O that map vulnerabilities to threat intel feeds. Tighter integration goes a long way towards prioritizing on realistic risks. Nevertheless, as evidenced by penetration test results, the gaps in asset and vulnerability management, combined with control weaknesses and architectural security concerns, offer the motivated threat actor a variety of ways to compromise an organization.

Five years of time, with not much progress to show for it. This has me saving a copy of my slide deck to give again in 2018.

What changes can we make to obsolete my Practical Risk Management talk? Simple. We can beef up and automate asset management. We can shift from the technical aspects of vulnerability management to the social aspects, facilitating remediation efforts with other departments. Finally, we can more tightly integrate threat intel with vulnerability management and begin doing regular red team assessments to identify architectural and control concerns. In three broad strokes, we can make a dent technical aspects of risk management and enable us to get out of the weeds.

Asset management. Vulnerability management. Threat management. Three areas, three programs, three ways to make a significant difference between now and 2018. The clock is ticking. Let’s get this done.

Tags:

Risk Management

Boulder rolling in Dark Reading

By wolfgang. 17 July 2012 12:29

My BSides Cleveland talk got some attention, and was part of a Dark Reading article on risk management. Check out 4 Reasons Why IT Security Needs Risk Management, also available as a PDF on my Press page.

"Traditional IT security has what I think of as a Sisyphus complex," says J. Wolfgang Goerlich, information systems and security manager for a Midwest financial services firm. "Every day, we roll the boulders up hill. We leave with as many systems, or boulders, secure as possible at the top of the hill. Overnight, new attacks are formed and new vulnerabilities are released. The next morning, some systems are insecure again, and we start again rolling boulders back up hill."

According to Goerlich and many of his peers, if security organizations are to evolve past that daily toil and affect meaningful change on their respective businesses, they need to embed risk management principles in their decision-making framework. "Moreover, rolling the boulder isn’t the goal of security, but rather the goal is securing the ability of the organization to accomplish its mission," he says. "Risk management is an important technique that focuses security efforts on the organization’s mission and prioritizes efforts on critical systems."

But what is important to the organization? What value does any given piece of technology deliver to the organization's mission? To answer these questions, we have to step back first.

The first step in building an effective security program is aligning with executive management and tying security tasks back to business objectives. Once that is done, we can move on to building a ITGRC function (IT governance, risk, and compliance). But executive sponsorship is key, otherwise, it will be extremely difficult to get feedback and support from the business units. The importance of this support cannot be overstated. Pierluigi Stella, CTO, Network Box USA, says: "Proper risk management is done when IT is only the project manager but every single business unit contributes its own knowledge to the process; and this needs to start from the top, from the C levels."

It is all part of building a mature information security program. For my full thoughts on building such a program, you can watch my BSides Cleveland Naked Boulder Rolling talk.

Tags:

Risk Management

Remediating IT vulnerabilities

By wolfgang. 17 October 2011 10:20

You might say that InfoSec risk management is effectively asset management, threat management, and vulnerability management. What do we have? Who would want to attack it? And what attack vector would they use? The prioritization of fixing or mitigating the vulnerabilities is based on business impact. That is, a measure of how such an attack would affect an employee's productivity and an organization's mission. The following article gives a good overview of the vulnerability side of the process.

Remediating IT vulnerabilities: Quick hits for risk prioritization
http://searchsecurity.techtarget.com/tip/Remediating-IT-vulnerabilities-Quick-hits-for-risk-prioritization

Use multiple information sources. As J. Wolfgang Goerlich, network operations and security manager for a mid-sized money management firm told me, he looks for reports that provide "solid information regarding what the threats are and at what frequency they’re occurring."

To keep the fix process focused and effective, know your environment and business impact, create meaningful metrics that take into account public and private ratings, and stay on plan with preset time-to-fix periods.

This article is also on my Press Mentions page.

Tags:

Risk Management

I fight for the users

By wolfgang. 12 October 2011 07:31

There is no patch for stupidity. L-users. Pebcak: problem exists between chair and keyboard. ID10T error. We had everything secure, but then we had to let the users on. We have all heard the jokes.

The problem is that this mindset sets us up against the users.

Corporate security teams need less "I fight the users" and more "I fight for the users". Yes, I am quoting Tron. Here’s a clip with the iconic line:

Tron: Legacy clip on YouTube
http://www.youtube.com/watch?v=vGG5vwH7mm4&t=0m52s

Security teams protect the organization’s mission and profitability. That fundamentally means protecting a user’s productivity. Protecting IT systems is secondary. That is a bit of a mindset shift, I know, but bear with me.

What does it mean to fight for the users? It means viewing IT security breaches in the perspective of the impact to the business's mission. It means viewing IT security controls in the perspective of the impact on user’s productivity. Fighting for the users is central to business-centric risk management.

Tags:

Risk Management | Security

Learning the wrong lesson from DigiNotar

By wolfgang. 23 September 2011 12:51

DigiNotar declared bankruptcy this week, following a high profile attack that lead to malicious certifications being issued. Some five hundred certifications were issued, for everything from Google, to Twitter, to Microsoft, to the entire *.com and *.org namespace. Major browsers quickly removed DigiNotar's root from the chain, thus protecting folks from these rouge certifications. And then DigiNotar was no more.

People are already saying this proves that IT security breaches put companies out of business.

I believe that is the wrong lesson.

Let's take four companies with high profile breaches: DigiNotar, Distribute.IT, Sony, and TJXX. DigiNotar went bankrupt. Distribute.IT? Shuttered. Sony is back to business (handling it with an update to their SLA.) TJX is unaffected.

So why did TJX survive? At first, this does not make much sense. But consider the attack as it relates to impact to the organization's mission.

TJX is in retail and has reasonably deep pockets. The attack did not so much as ruffle its ability to sell product. Save for a dip during the fall out from the attack, TJX did not suffer economic harm.

Sony is in the business of providing access to its services. Though the attack was not necessarily about availability, the attack severely affected Sony's ability to reach the customer. They have deep pockets, however, and are making their way back. The reasoning behind the service level agreement and terms and conditions agreements is to minimize the cost exposure of future breaches.

Distribute.IT was in the hosting business. Their job was to keep other companies sites online, available, and protected. The attack was an availability attack that was made worse due to mismanagement of data backups. Distribute.IT, without the cash reserves and without any means to get back to business, was dead in the water.

The attack on DigiNotar struck right at the heart of their business. The mission of a certificate authority is to safeguard certificates and ensure issuance only to legitimate entities. We are talking about reliability and authenticity attacks against a company that markets a reliable and authentic security service. Further, due to DigiNotar's limited reach (fewer than 2% of SSL hosts), there was little risk for the browser makers to remove DigiNotar's root.

The lesson here is security controls must be framed within the context of the organization's mission. Breaches can be weathered if the impact is low or in an area outside the core mission. Security breaches only put companies out of business when controls are not appropriately geared to the organization and when the financial impact is serious.

Tags:

Operations Security | Risk Management | Security

Impact driven risk management and business continuity

By wolfgang. 16 September 2011 23:43

InfoSec management hit the perfect storm. At the same time IT has exploded, budgets imploded. Our IT environments are growing due to consumerization, cloud computing, and sprawl. Our teams and budgets are shrinking due to the economic down turn. We are in an even tougher spot today that we were in 2008, when I began talking about the importance of driving information security from risk management.

We still have the same fundamental problems. How can we pitch the idea to our executive team? How can we secure this growing IT environment, when it is next to impossible to know what any one piece of it means to the business?

I have been driving my efforts from impact. We cannot defend what we do not understand. By mapping IT to the business activities it enables, and by performing an impact analysis, we can understand what all the stuff we are responsible for actually does. We can then tune the cost of security controls around the value of the IT assets.

Business continuity and risk management then flow naturally from this deeper understanding of our organization and how IT enables our organization to fulfill its mission.

These are #secbiz -- or security in the business -- concerns. I’d argue that impact driven risk management is a #secbiz approach. I made that argument today at a conference in Grand Rapids. I posted a copy of my talk online.

How asteroids falling from the sky improve security (GrrCon 2011)
http://blip.tv/j-wolfgang-goerlich/how-asteroids-falling-from-the-sky-improve-security-grrcon-2011-5561145

The next steps that I gave in my talk are continuing the conversation on Twitter under #sira and #secbiz, as well as joining the Society of Information Risk Analysts (SIRA) and the SecBiz group on LinkedIn. Please send some feedback my way. Is this is a good approach? What would make it better?

jwg


Note: This is the same talk. However, due to technical difficulties, the recording online is not the same as the one I gave in person. Same message, different out take.

Tags:

Business Continuity | Risk Management

Building a vulnerability management program

By wolfgang. 9 September 2011 05:47

Vulnerability management is one of the components of risk management. (The other two are asset management and threat management.) It is more than just keeping up on Microsoft patch Tuesday. First, the scope should include all your applications, operating systems, networking gear, and network architecture. Second, the process should include regular vulnerability assessments. And of course vulnerability management is an ongoing concern. What is secured today will be broken tomorrow.

Where to start? Diana Kelley has an in-depth article on building a vulnerability management program on SearchSecurity.com. "We will present a framework for building a vulnerability management lifecycle. Using examples from practitioners, you will get a from–the-trenches view of what works and what doesn’t when trying to win the ongoing vulnerability management war."

Framework for building a vulnerability management lifecycle program
http://searchsecurity.techtarget.com/magazineContent/Framework-for-building-a-vulnerability-management-lifecycle-program

I am mentioned a few times in the article. If you are a regular reader of this blog, you will recognize my themes. Start small and bootstrap your way to success. Bake security in: during evaluation and selection, during implementation, during operation, and during retirement. Integrate IT security with IT operations to reduce costs and increase security.

Ready to build a vulnerability management program? Definitely check out Diana Kelley's piece. She lays it all out in a logical fashion.

Tags:

Risk Management

Out and About: GrrCon

By wolfgang. 12 July 2011 14:12

I will be out at the GrrCON conference in Grand Rapids on Friday, September 16. I am giving a session in the InfoSec Management track. The topic is on business continuity planning and risk management. Sound boring? No worries. There is an amazing line up of speakers covering a wide range of topics. Hope to see you there.

How asteroids falling from the sky improves security
An asteroid fell from the sky and the data center is now a smoking crater. At least, that’s the scenario that launches your business continuity planning. BCP asks the questions: what do we have, what does it do, what is the risk and what is the value? The answers to these questions are also essential build blocks of a risk management program. This presents an opportunity for the savvy information security professional. In this session, we will look at ways to co-opt business continuity to advance an organization’s information security.

Tags:

Business Continuity | Out and About | Risk Management

Hello SSAE16

By wolfgang. 15 June 2011 09:42

As mentioned in my last, SAS70 has offically retired. SSAE16 (Statements on Standards for Attestation Engagement No. 16) has taken its place and improves upon SAS70 in several ways.

The improvements come from a shift of focus. SAS70 was about ensuring your control framework was sufficient and functional. SSAE16 is about ensuring your systems -- including deployment and controls -- are sufficient and functional. SAS70 was focused on the control structure around specific threats. SSAE16 incorporates risk management and ties together risks, threats, and controls. Going into this, SSAE16 looks set to provide a more complete result.

Another improvement is in the shift from audit to attestation. SOX (Sarbanes-Oxley Act of 2002) requires executive management to attest in writing to the accuracy of the financial statements. comparison, SAS70 does not require attestation. SSAE16 supports SOX by requiring a written attestation of the audit's accuracy from executive management.

SSAE16 should provide a holistic audit with greater executive management participation. This is the first year I have done one, and my audit period begins in a couple months. Wish me luck!

Tags:

Risk Management | Security

Goodbye SAS70

By wolfgang. 15 June 2011 08:29

SAS70 officially retires today, June 15, 2011. Taking its place is SSAE16.

SAS70 (Statement on Auditing Standards No. 70) is an audit framework that external parties follow to check the state of your controls. The audit is performed by financial services firms, and takes a top down approach. The objective is to ensure that financial results are recorded and reported accurately.

SAS70 has few common complaints: it lacks an objective technical spec, is carried out by CPAs at accounting firms, and misses technical details that leave businesses open to attack.

The SAS70 process emphasizes a truism that IT security folks sometimes lose sight of: the goal is securing the business’s ability to perform in the market. Though related, this is separate from the goal of securing all IT systems.

The SAS70 audit is top down and focused primarily on what drives the financial reporting. It is about prioritization. What is the top priority to a business? Financial success backed by accurate financial reporting.
 
A vulnerability assessment is bottom up. Your complete security audit would primarily focus on the IT domain, emphasizing technical controls and technical implementation. An audit here would tell you about your firewall ruleset and patching state, for example. What is the top priority for an IT security team? To not get breached.

These two priorities are not the same. Financial success does not prevent security breaches. Likewise, security breaches do not preclude financial success. Therefore, it makes sense to have separate auditor teams looking at the two separately.

As to the complaints of SAS70 audits, let’s step thru them with this background. First, there is no objective standard written into the SAS70 language. The result is that the applied standard is fluid and keeps up with the current standard of practice. Given SAS70 has been around for nineteen years, I think this speaks to the benefit of having an open-ended standard. Second, CPA firms rather than technology firms perform the audit. The benefit is that the resulting audit is driven from a financial perspective and scoped accordingly. The folks that I have worked with are very knowledgeable and are computer savvy, and often carry a CISSA or CISSP along with their CPA

So I found that SAS70 was a valuable tool for a top-down control assessment. As with all these standards, pairing the SAS70 with bottom-up technical assessments is necessary to truly secure an environment. The SAS70 had a positive impact on the industry, and I believe the SSAE16 is set to do the same.

Tags:

Risk Management | Security

    Log in