Published: February 03 2010, 11:38 AM | 1 Comment(s)
by Sumner Blount

A recent blog post http://bit.ly/bVd2i1 from Forrester Research made some very useful points, in my opinion.  The focus of the article was on flexibility, in two key respects.  First, flexibility is a key requirement of any GRC program, primarily because the demands for risk and compliance are so fluid right now.  There are clearly more regulations coming, but we don't know the exact extent of them, or how prescriptive they will be.   Some, like Barney Frank, are arguing for more regulations to prevent similar disasters to what we have seen in the financial services market over the past two years.  And I doubt if anyone would disagree that the impacts were severe, and were (at least for awhile) potentially catastrophic.

Others, notably financial service firms, are arguing that "excessive" (in the eyes of the beholder, obviously) regulation will stifle growth (read: profits and bonuses) of these financial firms, and is therefore bad for the economy overall.  [As a lengthy aside, I was intrigued by the comment from the Deutche Bank CEO who said "we should stop the blame game and start looking forward."  Have you ever noticed that anytime a public figure is faced with their mistakes, they always want to "avoid the blame game"?  I remember during the Katrina disaster, the Bush Administration argued strongly that we all should "avoid the blame game."  Sometimes I feel that a little blame would be a good thing!]

The point here is that we don't really know what's coming in the regulatory world.  As a result, GRC programs need to be designed in such as way that they can accommodate whatever comes down the pike.

The other area of flexibility that's relevant here is in the GRC market itself, in the sense that the market is evolving as we speak.  Over the past few years, compliance has generally been the primary driver for many GRC adoptions.  More recently, risk management has become a more prominent driver for many companies.  Similarly, we are starting to see the evolution of the GRC market to include more integration with CCM (continuous controls monitoring) solutions.  Many analysts argue that the distinction between these two markets will disappear over the next couple of years.  We at CA have been aggressively working in this area, having partnered with some key CCM vendors, as well as aggressively integrating our GRC Manager product with our broad security management product suite.  I think this is an obvious evolution, and one that will help reduce the "mini silos" of GRC and CCM across the industry.

In summary, "flexibility" is not only a key requirement for the success of a GRC program, but it's also an apt description of the ongoing evolution of the GRC market itself.

Share this post:  Email

Share

Published: January 28 2010, 04:37 PM | no comments
by Christine Needles

We're excited to announce that our board has unanimously elected Bill McCracken as CA's chief executive officer. Bill has been CA's interim CEO since John A. Swainson's retirement was announced in September 2009.

To learn more about the beginning of this new chapter in CA history, visit the press release , view his bio, or check out the recent clean energy interview he had with CNBC in December:

Share this post:  Email

Share

Published: January 28 2010, 08:40 AM | no comments
by Matthew Gardiner

I have been monitoring the case of Plainscapital Bank and Hillary Machinery since the news broke in November that more than $800K was apparently stolen from Hillary via the fraudulent initiation of wire transfers by criminals probably in Eastern Europe.  Brian Krebs recently posted a nice update article, which provides the necessary background.  In an ironic twist the bank has actually filed a suit against its customer, Hillary Machinery.  What the bank is looking for from the court is a "judgment that its security procedures are commercially reasonable" and thus it should not be held responsible for the remaining unrecoverable monies.  While I certainly can't pretend to sit in judgment on this particular case, since likely only some facts are on the table, the case provides a good framework to discuss the key issue of what is a commercially reasonable level of security and who is primarily responsible for online security.

Some points I would like to make around this from a security professional's point of view are:

• The primary responsibility for security should fall on the provider of the application or service, in this case Plainscapital Bank. Any security system whose function hinges on the user doing the right thing, is broken. The security system should always presume that the user will lose what should not be lost and will do and say what should not be done and said. Any important system, whether a spaceship, car, or security system, must start with the presumption that humans are unreliable.
• Was the bank in compliance with the FFIEC (a banking regulator) guidance published nearly 5 years ago that specifically addressed the security of online banking transactions? Quoting from this FFIEC report: "The agencies consider single-factor authentication, as the only control mechanism, to be inadequate in the case of high-risk transactions involving access to customer information or the movement of funds to other parties." If the bank was only using single-factor authentication complemented by other compensating controls that totally depended on the user doing the right thing, then I think the conclusion on reasonableness becomes obvious.
• Multiple-factors of authentication - using an authentication factor that the user can't wittingly or unwittingly "give away" - has been commercially available for many years. It doesn't sound like the bank was using a more reliable system of user authentication. While there was some discussion in the article around having customers "register" their computer's Internet address, presumably to act as another authentication factor, apparently this request was sent via email, which is not the most reliable system of communication. This approach also ignores the fact that Internet addresses can be easily spoofed and thus should not be significantly relied upon as a factor of user authentication. Security practitioners know that there are forms of multi-factor authentication that can be deployed without the user even knowing that it is happening.
• Risk-based authentication. Beyond multi-factor authentication discussed above many financial organizations use what is known as risk-based authentication to weigh the risk of certain on-line transactions (such as wiring large amounts of money) as measured by looking at certain factors, such as whether the customer is using his normal computer, the geographical location of the requester, how strongly the user has been authenticated, whether the financial counterparty is a new one or a long standing one for this particular customer, etc.

Based on what I have written above you can probably guess how I would rule if I were the judge on the case and the facts were as I assumed.  The fact of life is that there are serious criminals out there trying to steal money from all of us.  It is imperative that organizations remain vigilant and not rely on the users as their primary line of defense.

Share this post:  Email

Share

Published: January 26 2010, 09:05 AM | no comments
by Mike Hoefgen

The Problem
The Chief Information Security Officer (CISO) is given the mandate to ensure the IT department is compliant with these four authority documents: SOX, COBIT, PCI and ISO 27001.

The OLD Answer
The CISO reads and analyzes each of these documents and identifies the “thou must…” and “thou shall…” citations from each of these documents. He then uses that information to create a list of IT controls (activities) that must be implemented. How long would this take? Our CISO will have to read and study 448 pages and identify nearly 600 citations (yes, the citation number is accurate; I used the shortcut!).

Our CISO is not done yet, he has four lists of controls, one for each authority document. Looking at the four lists he sees duplicates between them. For example COBIT, PCI and ISO 27001 require management of cryptographic keys, so one properly implemented control can satisfy all three frameworks.  He will have to review over 700 controls looking for duplicates (yes, the number of controls is accurate, I used the shortcut).

Obviously, this is a fictitious example. In practice, compliance with these regulations would be divided into separate groups (silos) within the organization. Each group would be assigned to at least one regulation. This situation makes the rationalization of the controls even more challenging because more groups increase the communication and collaboration challenges.

The SHORTCUT
Take the shortcut by leveraging two years worth of work from a team of linguists, lawyers, compliance experts and practitioners. The product they created is called the Unified Compliance Framework (UCF) and it is quickly becoming the “Holy Grail” in GRC circles.

The UCF rationalizes IT controls from over 400 regulatory requirements, standards and guidelines into a single set of straightforward controls that clearly shows where global, state and industry regulations overlap, which dramatically reduces time, effort and cost associated with regulatory compliance efforts. At this point, you might be thinking this is great, but what happens when the regulations are revised? The UCF is updated on a regular basis. For example the Q4 2009 release includes 53 new or updated Authority Documents.

The table below illustrates our compliance example. Working with the UCF inside CA GRC Manager, I was able to dig up this information in an hour. That is a tremendous time savings when compared to the tasks our fictitious CISO had to perform. The UCF lists specific citations for each of the authority documents and their related controls. The critical point is that the controls have already been rationalized from 706 to 558. That’s a 20% reduction when compared to the “old” way of doing things with separate people listing controls for their specific authority document. 

The UCF can also be used to map your existing controls to authority documents. All you need to do is find a matching control in the UCF, then you can see all the regulations that could be satisfied by your ONE control.

In a recent article on the topic, Paul Roberts, senior analyst with The 451 Group, says companies that are bound by many requirements can identify areas that overlap and thus reduce their compliance costs by taking a "fix once, comply many" approach that will streamline internal audits and reduce capital expenditures.

At CA, we have incorporated the Unified Compliance Framework into our CA GRC Manager solution and extended the mapping capabilities significantly. In addition to mapping your controls to the regulatory requirements, you can also map your risks, policies, business units, business processes and business objectives. That mapping helps you identify different aspects of your business that are affected when a control test fails. You will quickly see all the relationships with that control and therefore can take appropriate action. 

Management is always looking for ways to reduce expenses and get more for less. The UCF can provide a good foundation that can help to reduce the total number of controls that you have to deal with, thereby simplifying management and reducing total compliance costs – an important benefit, to say the least.

Share this post:  Email

Share

Published: January 25 2010, 03:21 PM | no comments
by Chris Wraight

Whether the rumors that the Google breach was an inside job end up being true or not, just the discussion highlights what a serious issue the insider threat can be.  As technology to detect and block threats continues to evolve, it will become easier to pay someone on the inside to find vulnerabilities or do the job for you than it will to find a way in from the outside. It's similar to social engineering, but the insider is paid to act in a malicious way.

Technology should be put into place to limit employee access and activity. While it is important for companies to trust their employees, they should only allow them access to the data and systems they need to do their jobs. Some regulations require this! Appropriate controls and software should be in place to control access and monitor activity of all sensitive systems. 

The insider threat is not going to go away. It will continue to grow as an alternative or complementary method to gain access to systems and data. So the time to take action is now - before someone is swayed by the Dark Side.

Share this post:  Email

Share