The "RISKY BUSINESS" Blog

Had a very interesting conversation with the CISO of a Global 100 the other day. He was very concerned that there were risks that they were not fully cognizant of and was understandably concerned that one of them was going to rear its head and put them in the headlines. So the initial portion of the conversation revolved around the idea of conducting a broader Risk Assessment to ensure that all key risks had been identified.

To ensure the approach was optimum, we delved into "all things security" and I was impressed at the overall level of maturity of the control environment. A Systems Development Lifecycle (SDLC) Methodology was in place and operational and included the integration of key security elements (e.g., Risk Assessment / Security Requirements /S ecurity certification) at the appropriate project phases. As the conversation evolved, we jointly realized that many of the "suspected" and most concerning risks (e.g., privileged user access to databases, source code control, ability to comply with eDiscovery requirements) were symptomatic of a failure of the security requirements definition phase to fully document the requirements relating to monitoring / logging / compliance measurement.

The result is rather than conducting a Risk Assessment, we are going to address the "suspected" risks in a more direct/focused manner while at the same time making the necessary changes at multiple points in the SDLC to ensure that the aforementioned issues are addressed. 

Risk Management is by its nature circular ... so the "real" issue may require that you look at it through the back of the mirror

Over the last few years significant changes have taken place in the vulnerability discovery space. In the "old days" a vulnerability researcher would discover a vulnerability, report it to the vendor, wait an "acceptable" period of time (for the vendor to (hopefully) issue a patch) and then publically publish their work (and "exploit code").

Fast forward to today, the picture is radically different. Vulnerabilities are bought and sold by both hackers and security companies, often on the shady side of the internet. To anyone in the InfoSec field this is old news; So how does this change Penetration Testing?

Network Penetration Testing is a form of substantiative testing, with three predominant objectives:

• Determine the probability that a system vulnerability can be exploited
• If so, determine the impact that the exploit would have on the entity?
• If so, "shock" management into action by demonstrating the impact in a non-ambiguous manner.

With the number of exploits being "publicly" disclosed dwindling (because the vulnerabilities are being purchased by a security company or other hackers) the amount of "safe" exploit code available to an ethical hacker is dwindling as well. Without exploit code the ability to achieve those three objectives  is radically reduced. Ethical Hackers looking to still "exploit" critical vulnerabilities have two choices:

• Leverage potentially dangerous exploit code acquired from sites like millw0rm. (However, the exploit may actually contain additional malicious code leaving your client's machine compromised)
• License a commercial automated penetration testing application (e.g., Core Impact, Canvas) that is buying much of the exploit code on the market).
  

Frankly, I don't think either option is all that good.

The first encumbers both the ethical hacker and the client with significant risk. Questionable exploit code could contain malicious content resulting in an activity intended to improve the security posture of the network, significantly reducing it.

The latter adds considerable cost, reduces the likelihood that multiple "lower risk" vulnerabilities that can yield access (i.e., leapfrogging or privilege escalation) will be identified (as experience is replaced by push button automation), and reduces/distorts the ability to truly measure probability and/or impact.

We all (clients and ethical hackers alike) have some tough decisions to make. It's the end of network penetration testing as we know it.

To help put it all in perspective, be sure to review – “Stop Wasting Money on Penetration Testing" - on our Pen Testing resource page. You'll find valuable tips to help you properly determine your needs.

One of the hotter areas today is the integration of IAM and SIEM. When Identity & Access management (IAM) and Security Information Event Management (SIEM) are optimally integrated, user access compliance monitoring capabilities are increased significantly beyond what either SIEM or IAM can provide alone.

This is because IAM provides a context to user activity event data (e.g., role, entitlements, cross-referencing of multiple user IDs, account status) that can be directly leveraged by the SIEM to identify exceptions in real-time and initiate a workflow to remediate the issue. For example: triggering a suspension of all of a user's IDs and the initiation of a security incident after detecting that an individual attempted to access critical data using multiple user IDs, after access to said data had been terminated.

To this point the challenge has been getting IAM & SIEM to integrate (dynamically share information and allow processes to be remotely initiated). Fortunately, this has become much easier as those vendors that have both an IAM and SIEM offering (Novell, CA, IBM) have included the required integration into both IAM and SIEM on our behalf. I have had the opportunity to see the Novell Sentinel IAM/SIEM integration in action at a client site. It absolutely changes the way you think about security and compliance.

Click here for an excellent Gartner technical brief on the subject.

I found a recent report by Actimize to be reamrkably compelling. According to their research 72% of financial institutions have experienced a case of data theft by an employee in the last 12 months.

Interestingly, it's not the expected class of employees (e.g., outsourced/temporary) that is the greatest risk. The research shows that the insider fraud threat actually breaks down as follows:

• 70% full-time employees,
• 10% part-time employees,
• 8% outsourced workers,
• 6% temporary workers, and
• 6% offshore employees.

The challenge is that limiting user access to sensitive data is not a viable strategy in the banking arena. Branch managers, customer service representatives, call center workers, loan officers, tellers, et al, need access to view and change critical data to perform their everyday job functions. Traditional segregation of duty control mechanisms is also very challenging to implement while at the same time maintaining the high level of customer service that the industry demands. So what's the answer?

I think there are two inter-related Information Security approaches:

• Improving Human Resources practices (both prior to and during employment) to identify those individuals that are most likely to succumb to two of the three leading causes of fraud (financial distress & job dissatisfaction).  New and recurrent background check services are a great way to address this.
• Proactively monitor employee access to critical processes (e.g., address changes) on critical systems.

Neither approach is all that sexy, but both are not only great deterrents but also very good detective controls.

__________________________________________________

Link to the original Actimize article:
http://www.actimize.com/index.aspx?page=news216 

A colleague of mine recently forwarded the following list of “security maxims” compiled by the Argonne National Labs.  Highly recommended if you need a quick smile or two.

We have a maxim here that I was surprised was not on the list:  ”The information security posture of a system is often inversely proportional to the revenue it generates. ”  or alternatively, "The information security posture of a system is often inversely proportional to its business criticality".  On first blush, that may sound crazy, but if you think about it it makes a tremendous amount of sense.

Companies are often hesitant that a fix or upgrade will cause a problem, so the more critical the system is the more likely it is that we will hold off “for a bit”.  The next cycle we hold off a bit again, until eventually the situation is hopeless.

Consider the following examples from assessment projects we have performed;

• An online application that processes $8B a year of transactions that was running on a seven year old codebase and servers.  Virtually the only change made in seven years was the implementation of IPS in front of the solution to protect the solution from web application attacks.
• A "media" company that derives billions in revenue from a system that is dependent on PDP11, OS2, and DOS.  They scour eBay to find old 286 machines with clock speeds below 12Mhz because the code gets “flaky” on higher speed processors.

What to do if you recognize yourself in this blog?

Well-contemplated compensating controls can help you make the best out of a bad situation.