Seven steps to managing IT Risk

Came across this overview read from a Gartner research note recently. It lays out seven recommended steps managing risk.

• Implement a framework for risk assessment and mapping.
• Establish the responsibilities of risk managers with their areas of responsibility.
• Identify and define the risks to which the business is exposed and what constitutes a risk event or "near miss" so that incidents can be mapped to specific risks.
• Determine the threat level, and focus on those risks with the highest impact on performance.
• Establish levels of controls for processes commensurate with the perceived threat.
• Record and retain risk incident and near-miss information.
• Conduct periodic risk assessments to determine changes in the operations risk profile and assess control performance.

Great advice. These seven steps are precisely what IT-GRC solutions should help an Enterprise accomplish. They provide the construct (aka think configuration wizard) for establishing and maintaining a quality risk management program. If you have on your company priority list advancing the the risk mitigation/management capabilities or if you've recently been burned, take the time and check out some of our new product demonstration videos. We strive to be transparent around what we offer with our software. That's why our marketing isn't really "marketing" it's live product in action. Come check it out.

So now everyone is an IT GRC vendor

As a marketeer for a technology company, you work really hard to tease out the key points of differentiation and attempt to coin a segment that defines your being. IT-GRC (short for Information Technology Governance, Risk & Compliance) is a term that started gaining momentum about a year ago. At that time Gartner, Forrester, EMA and other research analyst firms started using it to describe exactly what Securityworks does. Next thing you know customers are achieving tangible results from these solutions and the press begins writing articles about it.

Then, along comes tangential segments that do 20-30% of what we do...now all of a sudden they are "IT-GRC" vendors since it's the new "hot" term.

Well, after all that hard work I have to simply say I love the candid article from Alex Handy over at Systems Management News. A couple quotes that say it perfectly...


When Jonathan Penn, research director at Forrester, walked around April's RSA conference, he was appalled by what he saw. “The vendors are destroying what's a very useful approach by claiming for themselves. If you're not an ITGRC vendor, just shut up,” said Penn.

“ITGRC is an incredibly valuable approach to security,” said Penn. “What I like about it is it's a good way to structure what IT does. But it's much more a practice than a product. The tools that manage things at a high level, those are the ITGRC products.”


We completely agree. No single product can encompass IT-GRC. Our product is a good foundation but what's so very important is the people, process and technology that mold around our product. This includes the integration points with other security products into a unified view of your overall security program, not those product calling themselves IT-GRC.

Evolution of IT Security to Risk; driving IT GRC acceptance?

Great summary by Michael Rasmussen of Corporate Integrity on the 2008 State of the GRC market was posted earlier this month.

I believe the title of one of the sections itself summarizes one of the biggest benefits of GRC, "GRC is About Organization Collaboration." He is 100% correct from my perspective - independent of the people, technology and process - GRC solutions are about using software automation to help enterprises collaborate to reduce their exposure to the big three buzz areas each of those letters in the acronym represent (Governance, Risk, Compliance).

Now, GRC solutions can't and won't solve these problems alone. They are part of an overall ecosystems of technical control products, best practice processes and people communication/expertise. You still need your Vulnerability, SIEM, IDS/IPS, Firewalls and other security products. You still need your COBIT, ISO, ITIL and other best practice processes. And of course, you still need the people who should know the overall business goals and priorities and then apply their expertise on how IT can help achieve those goals. GRC as mentioned before is the organization collaboration construct that can successfully bring all these complex areas together into a tight and cohesive Governance, Risk and Compliance strategy.

Another article I came across starts to highlight how some organizations are starting to elevate beyond operational security to strategic risk centric in culture. Tim Wilson over at Dark Reading just put out this great write-up yesterday titled; Market's Message to Security Pros: Adapt or Die.

-snip-
"...the question now is not how precarious the security manager's job is, but what it may evolve into, Schmidt observed. "As it becomes more about risk, security is not necessarily an IT problem. More and more, you see companies creating positions such as chief risk officer, who may report to a chief operating officer, and in some cases, the CSO might report to the [risk officer]."
-snip-

This trend points directly at GRC solutions that can provide the common construct to help all aspects of the organization collaborate. A decent analogy may be what ERP was to the CFO, GRC is to the CRO.

One last article that also points towards the trend around moving operational security tasks back into IT operations and thus security analysts evolving into internal Risk Consultants to the IT organization would be this blog from Trent Henry over at Burton Group. Once these "Risk Consultants" are created, GRC provides the collaborative platform to conduct their more strategic initiatives mentioned; policy, risk & compliance monitoring, assessment program development, etc.

Nice GRC write-up and how it relates to log management initiatives

Anton wrote a nice piece, called "Unified GRC: Replacing a piecemeal response to compliance" for SC Magazine defining GRC and how it fits together with other areas of security and prevention management. The article, as expected, has a major slant toward Log Management, but it is a very good summary that also highlights other key capabilities / areas important to GRC.

Even though most security vendors are marketing IT Risk Management, many customers are beginning to realize there is this new breed of software products that compliments your vulnerability, log, configuration security solutions. These IT GRC products normalize all the various regulatory or standardization controls into a common framework and then pull scores/results/data from these products into that model to go along-side data gathered from controls that can't be instrumented with software (e.g., people, processes, procedures, physical). As mentioned in previous posts, without this other side of the coin you're not getting a complete picture of risk/compliance/governance.

So if you you've already made investments in these other products but need something to pull them together into a unified view and are looking to get the complete picture, come check out IT GRC.

Great tutorial on Information Security Program Metrics

While reading a blog posting this morning I came across a great set of slides called "Measuring Security."

Slide 15 nails what are the questions security programs should answer on the head...
How secure am I?
Am I better off than this time last year?
Am I spending the right amount of money?
How do I compare to my peers?
What risk transfer options do I have?

Slide 36 has a great quote on "Risk Management"
The essence of risk management lies in maximizing the areas where we have some control over the outcome, while minimizing the areas where we have absolutely no control over the outcomes and the linkage between effect and cause is hidden from us.

The next 300 slides is a ton of background detail...overkill until your really ready to dig in. I would simply recommend for now jumping to slide 402 to get to the punchline; here are some of the recommended metrics:

• Cost of security per transaction
• DoS and other attack downtimes
• Data flow per transaction & per source
• Budget correlation with risk measures
• Comparison with like firms
• Percentage of critical systems under DR plan
• Percentage of systems obeying ______ policy
• MTBF & MTTR for security incidents
• Number of security team consultations
• Latency to obey ______ change orders
• Percentage of job reviews involving security
• Percentage of security workers with training
• Ratio of b.u. security staff to central staff
• New system timely security consultations
• Percentage of programs with budgeted security
• Percentage of SLAs with security standards
• Percentage of tested external-facing applications
• Number of non-employees with access
• Percentage of data secure-by-default
• Percentage of customer data outside data center

Where all this detail is extremely important, the beautiful thing about what Securityworks offers is it has built a method to normalize any/all metrics into a single score. Think of it as your grade point average where you then have the ability to drill-down from the top and see how your doing for each subject, on each test, homework assignment, etc.

Top 3 conclusions about IT Risk Management we like hearing

I read a nice summary of a recent Symantec 40 page survey on IT Risk Management and felt compelled to share the links and highlights that jump out. Symantec was recently noted as a leader in IT-GRC per this Gartner report.

The summary I read was posted by John Edwards over at ITSecurity.com.

Here are the conclusions that grabbed our eye:

• Businesses would be far better served if they viewed security as an IT risk management element that can be addressed alongside other critical elements, such as availability, performance and compliance.
• Technology alone can't mitigate IT risk. While technology plays a critical role in IT risk mitigation, balanced controls and frameworks are also necessary in order to provide complete risk management capabilities.
• Management should consider implementing a continuous risk assessment process.

Gartner IT GRC Predictions

I just had a chance to take a look at some recent research put out by Gartner on the IT Governance, Risk & Compliance Management space (IT-GRC).

They do an artful job laying out the customer desired capabilities and scoping the size of the market opportunity.

A couple key points to soak in:

• IT GRCM products provide functions that address needs expressed by 75% of the Gartner client base.
• Gartner estimates that software license revenue for vendors...was $73million for 2007, and we project a growth rate of 70% for 2008.
  

This reinforces previous posts with hard numbers that 2008 is indeed the year of IT Risk Managment. Here are links to those previous posts...

• 2008 - The Year of IT Risk Management
• 2008 - The Year of IT Risk Management, Part 2 - Rise of IT GRC
• 2008 - The Year of IT Risk Management, Part 3 - More and more GRC oriented predictions

I highly recommend heading up to Gartner's website and reading each report;

• MarketScope for IT Governance, Risk and Compliance Management, 2008
• Critical Capabilities for IT GRCM Tools

Then come take a look at how Securityworks can help solve your IT-GRC needs by accomplishing those defined needs and capabilities.

What is GRC vs. IT GRC - How does it help IT Security mature to the next level?

AMR Research shows that total GRC spending approached $30B last year. The technology portion (e.g., software, hardware & integration services) of that spending is around a third of it (approximately $10B).

GRC is a very broadly defined space - very broad! To gain a better understanding and appreciation for that, here is a newly released map that identifies various areas and their relationships.

Another AMR Research note talks about the current maturity point of Enterprises implementing GRC.

So where does Securityworks play in this "GRC Ecosystem?" We are coming at it through the eyes of an IT Security Executive.

Our goal - How can we make the IT audit process more efficient and less frustrating for the IT security organization? When you look back at the model above we fit in the area called "IT GRC" which leverages/compliments current IT security management investments (e.g., vulnerability scanning, configuration policy management, SIEM) to accomplish this. If your enterprise already leverages these products then its ready for the next step in the maturity curve, which is IT GRC. Just to get an idea of some the unique capabilities that extend your current IT Security investments please check out our newly posted product demos. Live product in action, no sign-up requirements, etc. Just pure knowledge.

Compliance costs not slowing down - technology automation to the rescue

Deloitte - Navigating the Compliance Labyrinth offers some great tidbits from recent surveying of financial executives.

• Compliance continues to increase - from 2.83% of net income in 2002 to 3.69% of net income in 2006.
• Primary costs continue to be driven through applying people, not technology to the problem.
• and the kicker from our perspective, measuring compliance performance remains largely a qualitative rather than a quantitative process. Only 55% of financial institutions reported using quantitative metrics, implying a limited application of process management tools and methodology.

Forget the name of the segment (e.g., GRC, IT-GRC, ERM, VM). The bottom line is taking a process management based approach with technology. Commercial solutions (not home grown) that offer enterprises the opportunity to leverage technology automation to reduce people doing mundane/manual tasks producing the result of reduced compliance costs!

Another security breach, but this one is different...

Late last week I saw the news around local JC Penney's hit the wire - "Data of 650,000 customers at risk." Now this situation appears completely different then TJX. The data, and I assume the protection of that data, were outsourced.

So this begs the question - should it be a requirement for vendors providing services to enterprises that would include sensitive data be certified against ISO 27001?

Here is a great write-up, case study I came across of a vendor doing this. Just like we expect vendors to achieve specific Service Level Agreements on availability, performance...shouldn't we be doing the same things around security and risk?

So much to read, so little time - Top Information Security Risks for 2008

Now this is impressive! It's going to take a while to read the supporting reference documents, but this summary is gold and from my perspective a must read for IT Risk Management.

In the primary summary document, "Top Information Security Risks for 2008" we get an impressive laundry list of threats & vulnerabilities, their impacts, the risk and the controls. Page 5 talks of specific risks, some can be addressed with various technical control product on the market, example: #2 - Information Leakage. If you want to get down and dirty understanding these products spend some time with Rich over at securosis, specifically his blog entries and the summary which formed this white paper around understanding & selecting DLP solutions.

This section also highlights non-technical controls, audits etc in #5: "poor information security studies, risk assessments, projects/assignments and/or staffing/organization, causing failed, wasted, excessive or otherwise inadequate controls and practices selection, implementation, performance measurement, monitoring and/or auditing." Wow, that's a mouthful! But this is exactly what IT GRC is all about. Through using these software platforms you can evolve from poor, ad-hoc attempts at mitigating this risk while ensuring your enterprise takes a comprehensive, top-down look at any and all potential risks and assess their potential impact. If you then go down to #1 in the controls section of the document you will see what in my eyes is basically an advertisement for an IT GRC solutions and the process around deploying it, "investment in a good and systematic ISMS (Information Security Management System) incorporating high quality information assurance processes..."

A key statement back in #5 of risks that I was surprised to see was the calling out of "excessive" controls. This is something we at Securityworks (especially Bryan) are passionate about. Some vendors in the IT GRC space believe in throwing the entire "book of controls" at it, and you will be fine...we believe its about making sure you have quality controls in place, not simply quantity. Bryan has talked about this previously.

2008 - The Year of IT Risk Management, Part 3 - More and more GRC oriented predictions!

I keep thinking I'm going to be able to move onto other topics related to IT Risk & Compliance management but it's hard to when my blog reader keeps popping up more and more articles and postings which talk about 2008 predictions and how GRC and IT GRC are going to be the "in thing" this year for IT Security groups.

IT & Compliance: 5 Big Predictions for 2008 hightlights "...Managerial evolutions, such as process-centric IT and better application of risk-management principles to information security management, will help companies refine and streamline IT governance and compliance."

The post continues on later with two of the five predictions hitting on capabilities or features of IT GRC products.

2008 - The Year of IT Risk Management?

I've been busy over the holidays enjoying everyones blogs and articles recapping 2007 and making predictions for 2008. Among other things highlighted in those articles, a common point pertains to Securityworks around "true" IT Risk Management (what I mean by "true" is the message is coming from companies who didn't adjust their marketing to be en vogue - e.g., SIEM products or Vulnerability Assessment products).

Before IT Risk Management was "cool" Securityworks has been out their working away on it (for over 4 years now).

One of my favorites that highlights this prediction for 2008 is over at Rational Survivability.

-snip-

Compliance stops being a dirty word & Risk Management moves beyond buzzword
Today we typically see the role of information security described as blocking and tackling; focused on managing threats and vulnerabilities balanced against the need to be "compliant" to some arbitrary set of internal and external policies. In many people's assessment then, compliance equals security. This is an inaccurate and unfortunate misunderstanding.

In 2008, we'll see many of the functions of security -- administrative, policy and operational -- become much more visible and transparent to the business and we'll see a renewed effort placed on compliance within the scope of managing risk because the former is actually a by-product of a well-executed risk management strategy.

We have compliance as an industry today because we manage technology threats and vulnerabilities and don't manage risk. Compliance is actually nothing more than a way of forcing transparency and plugging a gap between the two. For most, it's the best they've got.

What's traditionally preventing the transition from threat/vulnerability management to risk management is the principal focus on technology with a lack of a good risk assessment framework and thus a lack of understanding of business impact.

The availability of mature risk assessment frameworks (OCTAVE, FAIR, etc.) combined with the maturity of IT and governance frameworks (CoBIT, ITIL) and the readiness of the business and IT/Security cultures to accept risk management as a language and actionset with which they need to be conversant will yield huge benefits this year.

-snip-

Well said (but then again I'm biased)!

IT Risk Management vs. Information Security survey

I was playing catch-up on blog reading and came across this interesting post by a favorite blogging colleague of mine, Anton Chuvakin, "Review of my 2007 Security Prediction: Too Wimpy."

Prediction #4 about Risk Management lead to some very intriguing survey results. Here is a copy of the graphic from those results which says it all...




A personal point I can add here is this actually makes some sense to me.

Here at Securityworks we are 100% focused on talking IT Risk Management. When I talk with customers they are usually talking (strategic = risk) vs. (tactical = security). Another thing to realize is IT risk encompasses more then technical control monitoring/management solutions (that is only 50% of the scope as discussed in my previous post). IT Risk also spans people & processes (e.g., non-technical controls). Since that typically requires getting into process improvement it is naturally discussed as a strategic initiative due to the time/effort associated with it.

So now with 2007 ending and looking ahead to 2008 we should be trying to use this opportunity to be more strategic before tactical day-to-day tasks re-consume us. IT-GRC solutions (which Gartner, Forrester, etc are calling these solution) help you do this! So go ahead, take a look...this is going to be a hot area for 2008 based on what I'm seeing and hearing for a variety of reasons.

Healthcare Best Practices Security Framework

We are excited to see this announcement about the formation of HITRUST (Health Information Trust Alliance). A health care vertical specific initiative around establishing and collaborating on information security best practices. Why are we excited, our solution (along with other IT-GRC solutions) are specifically designed to enable a major enterprises to consolidate, centralize and simply organize from the top-down their Information Security Framework in an actionable, track-able way.

Is IT Risk Management the Union of IT Security & IT Operations?

This morning I read this statement from PCI Expert James Deluccia IV and it struck a cord...

-snip-
The best risk management initiatives don't simply protect data, they help the company to run more effectively," he said. "This is the case when equal consideration is given to areas like system continuity and service delivery that support operational measures. It's the blending of business necessity with core methods for data security that ensures overall risk management."
-snip-

Over the last couple years I've read and heard about the pending convergence of Security & Operations Management but we still haven't really seen it occur. With more and more attention being given to Risk, maybe it's right around the corner.

After reading this snip it reminded be of emphasis applied to programs/organizations embracing TQM or other re-engineering practices back in mid-1990's. Security and Operations Managment are rooted in tactically solving pains; Operations focuses on keeping IT resources up and running while Security focuses on protecting those IT resources. Those two ideals, time to time, come into conflict. By taking a business goals driven, "quality-oriented" look at IT fromthe top-down we may find a union between Operations & Security.

The snip was found in article "PCI Expert James DeLuccia IV Suggests Retailers Address Both Sides of Risk Management - Security and Business Availability"

Users continue to ignore security policies, while security organizations are overlooking non-technical controls

IT Compliance Institute had an article posted this morning that reinforces the point; "it's not the software/hardware/infrastructure/etc but the people and processes that expose the biggest risks to a company.

The article doesn't reveal who/where the survey was taken but it does highlight some key security items that people usually cut corners on.

• Fifty-six percent said they had accessed office e-mail via a public wireless hotspot
• 52 percent said they had accessed office e-mail via a public computer.
• Eight percent admitted to having lost a mobile device containing corporate information.
• Sixty-three percent admitted to sending corporate documents to their personal e-mail addresses so they could work at home.

There are security technologies out their (e.g., encryption, data leakage) that can help with each item but the challenge is keeping up with other IT technologies being deployed and business demands/challenges the users are trying to productively solve. Bottom line, you can't bypass making sure you have the right policies, procedures and education in place for your users (aka non-technical controls).

After reading this I decided to do some searching around for some type of survey numbers around technical vs. non-technical controls. I didn't see much out there but did come across this ("Is Information Security Under Control') from IEEE Computer Society published in early 2007.

The survey focused in on 80 of the highest quality security controls as determined by a group of experts. From that list of 80 their wasn't a place that specifically counted the number of non-technical vs. technical controls BUT, there were two very interesting graphs.

The first one (figure 2 in the article. - see below) showed the top 10 with the highest level of quality implementation. It revealed that 6 are technical controls and 4 are non-technical controls. Meanwhile, the second graphic (figure 3 in the article - see below) showed the bottom 10 related to quality of implementation. It revealed that 3 are technical while 7 were non-technical.



So just running crude number here shows 11 of those 20 were non-technical controls while 9 were technical controls. The articles goes on to make the statement "...we found that of all 80 practices surveyed, management controls (non-technical controls) had substantially lower implementation ratings then controls in the technical and operational categories... Organizations must realize that a large proportion of information security problems extend far beyond technology and learn to appreciate the role that less technical controls, such as policy development, play in minimizing security breaches' impact on mission-critical operations.

So this begs the question, "when was the last time your security group considered software products that help with managing these non-technical controls instead of just technical controls?" I've talked with numerous enterprises that have installed or are investigating various software products like Vulnerability Assessment, Patch/Configuration Management, Antivirus, SEIM, data leakage, etc. Maybe it's time to do something for your non-technical controls also and consider adding IT-GRC products to that 2008 budget/priority list.

Industry trends - Survey results on Risk Management

Industry trends - Survey results on Risk Management -
Posted by: Ryan Shopp

While Bryan continues to blog about practical experiences in IT Risk Management, I'm going to aggregate some key trends and insights on the industry as a hole. As previously promised, we will continue to stay away from product advertisements, etc. Just useful (hopefully) insights.













The Convergence of Physical and Information Security in the context of Enterprise Risk Management. Survey and report conducted by Deloitte.

some key points/snippets from the report:

...As it stands today, senior management typically sees security more as a tactical function than a necessary component of business processes or decision making.

...one of the challenges that must be mastered to achieve value is “integrating security strategy across the enterprise.” Rather than approach security in an uncoordinated and functionalized fashion, businesses need a top-down approach coordinated by a senior executive to
optimize the effectiveness and efficiency of the overall security system.

...for effective risk management, it is necessary to:
• Adopt a common operational framework
• Reduce autonomy while retaining authority
• Collaborate on all forms of enterprise security risks
• Provide better risk information for decision making
• Go beyond data sharing to collaborative planning and decision making

The document is over 50 pages long and also includes example case studies and a ton more graphics with survey results etc. A must for any organization looking to better align their security program with business initiatives and goals. The document even offers a risk management maturity model and insights around climbing up the maturity model.

Is Risk-Based Security Really Possible?

Yes. Few security professionals doubt that our job is all about risk mitigation. But there tends to be sharp debate about whether you can measure risk. I think you can and should, but quantitative models don't work. I'll come back to "why you should" and "how you can" another time, but for now I want to discuss why the quantitative approach doesn't work.

The classic textbook quantitative risk calculation is Annualized Loss Expectancy:

ALE = (Impact of the event in $$) * (Number of times in a year the event will happen)

So, you calculate your ALE and that's the maximum you should spend to mitigate that risk.

If the real world was that simple, we'd all use ALE to plan our security strategies. But ALE is fundamentally wrong for for information security. I'll concede that ALE can be useful as a simple conceptual model for risk because it requires us to think about both of the factors that generally influence risk: Likelihood and Impact. But literal use of ALE for information security decisions is problematic to say the least.

The problem with ALE is that the numbers we plug into that formula are so baseless that the resulting calculation has no credibility. We probably inherited this simple conceptual model at some point from the insurance industry, which is different from security management in at least two key ways:

• They have statistics and actuarial models that predict the likelihood of certain events with reasonable numerical accuracy across a certain demographic - we don't
  
• They have a straightforward way of estimating the loss associated with those events with reasonable numerical accuracy - we don't

Not to mention the fact that insurance and information security are fundamentally different models, but I'll save that tangent for another time.

How does one calculate the financial impact of a security breach? Here's a hint: the amount of money you paid for the server that was just compromised is wrong. There's a whole bunch of things that go into it... the cost of employees and consultants to restore order after the breach, the potential legal liability, the cost of business you may have lost when the system went down, the opportunity cost of things you couldn't do because you had to spend time and resources responding to the incident, and the impact of lost goodwill and reputation damage that you suffer in the market. All of these factors are either immeasurable or unpredictable, which makes them poor candidates for mathematical calculations.

How does one calculate the likelihood of a security breach? The spectrum of threats is too broad and too unpredictable to have any hope of doing this. If you were just hacked by an outsider, or fell victim to a disgruntled employee, or made a simple mistake and exposed a bunch of sensitive information on a website, chances are you never saw it coming, and sure couldn't have sat at your desk six months ago and said "there's a 20% chance that this will happen in the next year".

So, with ALE hopelessly wrong for information security, how can we argue in favor of risk-based security? The answer lies in qualitative models - stay tuned.

Cheers,
Bryan