Monday, March 24, 2008

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.

Labels: , , , , , , , ,

Monday, March 3, 2008

Going beyond technical security controls

Anton last week had this great write-up in ComputerWorld, "Five Basic Mistakes of Security Policy," that hits the 5 basics that so many busy executives look past when leading a security organization.

  1. Not having a policy
  2. Not updating the policy
  3. Not tracking compliance with the policy
  4. Having a "tech only" policy
  5. Having a large, unwieldy policy

One of the biggest we see every day is #4. Most enterprises have some policy in place that they update (typically annually before a pending audit). Their current compliance tracking is provided by one or more software products that unfortunately don't have the full picture.

The reason why comes down to #4. Traditionally, enterprises have thrown either a vulnerability scanner, security event/log manager or another security software application at a list of IP addressable assets...generate a few reports...and hope they have things covered.

The truth be told, this misses so much of the full picture (over 50% per previous blog posts) that even the internal or external auditors don't have enough time to do a comprehensive review. The goal of those auditors is not a "witch hunt," it's suppose to be to protect the company! So what happens is each year, things get more and more detailed (which is good) as findings from the prior year are addressed allowing them to "peel the onion" back another layer.

This is why we are seeing the emergence of the IT GRC market that compliments and extends these products you point at IP addressable assets. These solutions use automation techniques to assess security controls around things that are not IP addressable (e.g., people, processes, facilities). The other need these products are offering is a normalized, unified view of the entire security program. Leveraging scoring from other products, they finally deliver the possibility of 100% visibility into the posture of your entire IT security, risk or compliance program.

Labels: , , , , , , , ,

Monday, February 25, 2008

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.

Labels: , , , , , , , , , ,

Thursday, December 13, 2007

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.

Labels: , , , ,