The "RISKY BUSINESS" Blog

Lost in the glow of Operation Aurora was the American Bankers Association (ABA) recommendation “that small to midsized businesses only conduct online banking on dedicated work-stations”.  On first blush,  sounds like sound information security advice; so why is it that I find this so significant?

Because the banking industry  finally “gets it”. 

When the ABA (dedicated to enhancing the competitiveness of the nation's banking industry and strengthening America's economy) suddenly throws a wet blanket onto online banking we have reason to be concerned.  In short, what they are saying is that online banking is only as secure as the end-point that it is conducted on and that the viruses, spyware, Trojans and identity-stealing key-loggers that regularly infect computers are something they no longer can pretend they can control.

They finally get that HTTPS, strong passwords, and two-factor authentication can’t keep us safe from ourselves and the increasing risk posed by organized crime.

Unfortunately, the proposed solution, while it may be the best we have, is insufficient.  Even a dedicated workstation is vulnerable to malware infection, even if “safe” web practices are followed (comically, AVG just reported that I happened upon a malware loading site following  a link on organized crime and online banking while researching this post).  What we need is a trusted, fully immutable, computing device – I have to think someone really smart is working on this right now.

In the meantime, I’m not worried enough to give up on online banking.  However, I won’t do it from a windows machine any longer.  Right now, I’m only using my iMac, but plan on moving to either a dedicated Ubuntu machine or a bootable USB Linux. 

I thought this blog post on “more secure” options for online banking was well done.

Much Ado About "nothing" ... A Very Significant "nothing"

Unless you have been living under a rock for the last few weeks you are likely aware of “Operation Aurora” – the Chinese state sponsored cyber attack on Google and at least 20 other prominent US firms (Adobe, Juniper, Rackspace, Yahoo, Symantec, Northrop Grumman and Dow Chemical).  It’s a big enough story that our clients have enquired as to why we have not blogged about it to this point.

Honestly, in much the same way that Seinfeld was a show about “nothing” (the Chinese Restaurant episode where the entire episode is them waiting for a table, is perhaps the best example), I look at the Operation Aurora story the same way (the irony of using the Chinese Restaurant episode is not lost on me.) 

The only thing surprising about state sponsored cyber attacks against key US companies is that people were surprised by it.

Over the last five or six years we have seen a steady increase in the number of projects where we have helped defend our clients against industrial espionage, insider attacks, and cyber-attacks by organized groups.   Even more “telling”, we have been approached by “potential clients” with malicious project opportunities: hacking into Gmail, industrial espionage, eradicating evidence of criminal activities in advance of an FBI forensic investigation, etc. (needless to say our hats are white and these potential clients were rebuffed. 

Seinfeld was significant in that a show about “nothing” was really something, and that “nothing” became part of our collective cultural consciousness.  Operation Aurora is significant in that  “nothing new” has been escalated in the media to a point where it may become part of our collective information security consciousness. For that reason … it was a very significant “nothing” – and will hopefully have a positive impact on our understanding of evolving information security risks.

With apologies to Mel Brooks ...  

As a firm that performs security assessments we are pretty familiar with dealing with sensitive data and go out of our way to handle our client's sensitive data appropriately.  We recently finished an engagement where we identified flaws in an extranet business application that exposed sensitive Personally Identifiable Information.  We encrypted the report and sent a one-time HTTPS link to the document and left the password for the doc on the client's voice mail.

An hour later the client's Director of Information Security  forwarded a non-encrypted email to his internal team, the (outsourced) application development team, me, and the Application Server vendor's tech support -- detailing our exploit.

When I "politely" mentioned to him that forwarding the information in an un-encrypted email to a broad audience had put them at risk and violated their policies (which we had signed at the project outset), he fliply replied, "It's good to be the king." 

We had lunch together today and he almost immediately revisited the subject and acknowledged it as a mistake that he had reviewed with the impacted members of his team and vendors. 

I was relieved -- as the single greatest predictor of an organization's security posture is the "tone at the top".

In one of the most remarkable stories involving Information Security I have read in a while ... insurgents used $29 software to monitor the video feeds coming from our drones (and we wonder how Bin Laden is still standing upright?)

To be clear ... drones which cost as much as $12M apiece don't encrypt their video feeds.

So think about this: my son's XBox Online "Modern Warfare" traffic is encrypted but our military's "real warfare" traffic  isn't?  Now that's scary ... 

Last week I bemoaned Axe Shower Gel's packaging and noted that we were working on some changes to our Penetration Testing service offerings to better meet our client's assurance objectives.

Over the last 9 years we have found you can generally divide our Penetration Testing clients up into a few broad "stereotypes", clients who:

1. View a penetration test as a necessary evil (e.g., small banks and smaller SAAS providers who conduct them to satisfy a regulatory or customer requirement).

2. Are pretty confident that they have things "screwed down tight" but just want a quick test to make sure.

3. Have a business driver (e.g., regulations, client attestation) and consider penetration testing to be integral to their security program (e.g., larger banks and SAAS providers).

4. Operate in a high threat/high impact environment where penetration testing is viewed as critical (e.g., critical infrastructure, law enforcement, eGovernment).

Recognizing that "one size" doesn't fit all, we have tried to align our Penetration Testing offerings to provide assurance consistent with our clients' varying objectives:

• An Investigative Pen Test - emulates an attacker that doesn't have a lot of time, and doesn't have a lot of tools, and may not even be targeting you specifically. He may stumble upon an interesting portion of your infrastructure during a broader sweep and will leave  relatively quickly if he doesn't find an obvious security problem. Attackers that get in through a blank or default password on an administrative account are Investigative Attackers.

• An Intentioned Pen Test - emulates an attacker that has more time, and a few more tools than the Investigative attacker. More importantly, she has intent. She is targeting you and wants to find a weakness in your network. Attackers that get in by exploiting an unpatched vulnerability in an operating system or network service are Intentioned Attackers.

• A Tenacious Pen Test - emulates an attacker that has time, tools, intent, and determination. She is willing to go the extra mile to make it past your defenses. She may even attempt social engineering to find a way beyond your perimeter defenses. She will do it quietly, though, and take care to go unnoticed. Attackers who convince your help desk to reset an account password for them are Tenacious Attackers.

• A Zealous Pen Test - The primary difference between a Tenacious Attacker and a Zealous Attacker is that a Zealous Attacker won't try to stay under the radar. He will do things that get noticed. He may even intentionally disable access to services to see what happens. More than intent and determination, he has a belief that he needs to breech or damage your systems, one way or another. If he has any worries about covering his tracks, they are secondary to the success of the attack itself. Attackers who crash your mail server and deface your website are Zealous Attackers.

Just as packaging matters when it comes to shower gel, we believe it also matters when it comes to security testing. So choose wisely, and dispense exactly what you need. Remember, "one size does not fit all!"
 

Just spent the finer part of my afternoon in a meeting further refining our Penetration Testing services to better align with the differing objectives of our diverse client base. Many of our banking clients want a penetration test for one reason (and one reason only), to hand to the FDIC/OTS/SEC auditor to satisfy their requirements. On the other end of the spectrum many of our government clients want a high level of assurance that a knowledgeable and intentioned malicious individual with an extended time window can't gain access to certain facilities/systems/data. The challenge is that as an industry we have failed to "package" Penetration Testing in a manner that is relevant and easily consumable. Only intelligent and innovative consumers can wade through the idiosyncrasies of the varying ill-defined activities to arrive at a solution that is optimized to their requirement.

I have overcome a similar challenge to the one I just raised, in my shower. I have recently grown fond of the Axe shower gel my son left in our shower. The problem is that the packaging is almost comical. It's in an oversized bottle that becomes as slippery as a watermelon seed the minute that it gets wet. It's virtually impossible to squeeze out anything but 3X the amount of gel that you need to cleanse your entire body. Worse, you lose most of down the drain before you can leverage it across more than a single leg and midriff. So, back to the bottle, which is impossible to pick up now that your hands are soapy, and repeat the folly.

Problem solved. I bought a $1.49 foaming hand soap product, dumped the hand soap, and watered down the shower gel 5 to 1.  Life is good: oodles of perfectly fluffy shower gel foam with nary a drop wasted.

So why is it that the multi-billion dollar consumer product companies haven't properly packaged shower gel and we have to live with a one-size-fits-all ill-packaged offering?  My guess is they don't know enough to know, they don't actually use shower gel themselves, they make more money with a poorly designed product, and they don't think we are smart enough to differentiate product offerings.

I wish there was a $1.49 (Walmart) solution to the penetration testing packaging as well. Unfortunately, it's not quite that easy,  but we are confident that we have solved the problem and that our clients are smart enough to differentiate the product offerings and ultimately benefit from our approach. We'll be rolling out our new services over the next few weeks ... so please stop back.

For further information, check out our white paper – available for download – “Stop Wasting Money on Penetration Testing" - on our Penetration Testing resource page.

So the childish side of me wants to say I told you so ... but I'm above that so I won't.

It's been a while that we have been banging the ISO27001 drum. So the recent influx of significant cloud computing organizations like Microsoft and Salesforce.com is only a surprise in that they got on the wagons sooner than we thought they would.

What does this mean to you?

If you work for a company that needs to provide third party attestation -- quite a lot. It means the tipping point on 27001 being the de facto form of attestation is nearer than we thought -- likely less than 18 months. So if you don't yet have an initiative in place - it's probably time to do so.

Where third party attestation is not required its less clear what this means. Best guess is that ISO27001 will become somewhat "de rigueur" in that you will have to rationalize why you chose not to align yourself with the standard to key stakeholders and management (rather than the converse).  I think it's hard to rationalize against leveraging a well vetted framework that simplifies Information Security by providing a method to our madness. Interestingly I had a conversation this week with the CISO of a $5 Billion entity that has no attestation requirements - yet he wants to move to ISO27001 for just that reason.

For an Intro to ISO 27001, download a copy of our CSO presentation.

Or, review a Case Study for ISO 27001 by clicking here.

We are fortunate enough to work extensively with across both government and private sector clients. The two biggest differences we notice are that government entities are much more risk-intolerant and that most government entities employ some form of Security Certification & Accreditation (SC&A) process.

Figuring out why most government entities run SC&A is pretty straight forward. Being risk intolerant, means that you are going to spend whatever dollars are necessary to mitigate the biggest risks. Large projects (e.g., moving your core accounting application off the main-frame to a 3 tier J2EE architecture) that embody significant change embody significant risk, hence, lets ensure that the application is secure before we deploy it (SC&A). Another driver, is the federal government advocating (or mandating) SC&A (e.g., NIST 800-37) for federal entities, which has trickled down to many states and larger cities.

What is not as clear to me is why private sector companies don't have formal SC&A processes. Any information security professional worth their weight in salt knows that change = risk. So why are so many systems deployed without sufficient testing? I wish this was where I came up with a clever answer, but I have none. I'm hopeful that advances like SAMM will change the situation.

Dear X,

At the close of our meeting you asked me to follow up with a proposal on how I think we (jointly) should approach your information security/information assurance requirements relating to (insert your relevant regulatory compliance issues here).  As you already know, I don't yet have enough knowledge of (insert your company name here) to answer that question definitively.  But "I'm not sure yet" is neither confidence inspiring nor all that useful.  So based on the four main ideas I took out of our meeting  (bullets below) I will lay out my best guess as to what our (joint) approach may be. 

PRIMARY CONCERNS:

• You have a growing demand to "prove" that you are compliant with relevant laws and regulations (most notably HIPAA/PII) which is challenging and time consuming.
• You have a relatively good security posture, although it lacks in documentation and formality.  This results in you feeling good about the 95% you "know", and nervous that the 5% you're not sure about is going to come back to bite you.
• The reason you are where you are, is that you have insufficient resources (time/training/manpower) to address security/assurance/attestation at a more "strategic" level.
• You are looking for a roadmap to confirm the 95%, address the 5%, and simplify the process of proving you are compliant with relevant laws and regulations to management and customers.

RISK-DRIVEN APPROACH
Our approach should be risk driven.  Fortunately, it does not seem as though there are any "urgent" risks that need to be addressed immediately,  which gives us greater flexibility in our approach.  Beginning with the end in mind is a fundamental tactic, so determining what the overall "target" is for our control environment is going to be helpful .  For now, I would restrict our efforts to the information security realm to ensure that we don't end up in a "boil the ocean" exercise (later we can look at integrating our information security controls into a larger Information Technology Control Framework like COBIT if it is warranted).   From an information security framework perspective, I'm a fan of ISO 27001 for a couple of reasons:

• It's proven: ~ 7,000 companies are already leveraging it, and ISO 17799 from which it is derived, has been in place over ten years and has been used by tens of thousands of organizations.
• It's an international standard that is "recognized" by everyone and is widely regarded as the de-facto standard by most.
  ISO 27001 has  been  "mapped" to HIPAA/PII and can be easily mapped to any new standard that you may need to comply with.  This simplifies proving compliance.
• It's certifiable (like ISO 9001) meaning that you can get those portions of your environment that are relevant to the handling of client data certified to be compliant with the standard by an independent entity.  This is the best possible form of attestation.

Alternatives include: a roll your own approach, the BITS Shared Assessment program (more financial services oriented) and HITRUST (purely Healthcare-centric).   I'm pretty confident that ISO 27001 would be the optimal approach for you.

PLANNING FOR ISO 27001
Assuming you agree, and you are not under any  short term requirement to be certified,  I would recommend a 1 - 2 year time target for certification.  You can try to do it faster (if necessary), but the controls in a strong control environment are highly interdependent and trying to move too far too fast often results in sub-optimal results.  Further, doing it faster would drive much of the work effort external to your organization and we have found that ensuring  your key folks are true stakeholders, is very important to long term project success.

Gaining Senior Management buy-in is also critical.  A 27001 Gap Assessment is the best way to get a sense of the work effort necessary to get to ISO 27001 certification and communicate the staffing/budget requirements for the same.  So a Gap Assessment would likely be the first activity relating to ISO 27001, and would provide a measure of where we are,  where we need to get to, and what it will take to do so.

MANAGING THE "INTERIM"
One challenge to the approach outlined is "proving" you are secure to customers/business partners in the interim (between now and ISO 27001 certification).  An approach that we usually (successfully) employ is to use a Vulnerability Assessment and Penetration Test (VA/PT) to "substantiate the net-effectiveness" of your current control environment.  In addition to being short term attestation, the VA/PT also provides valuable input into the ISO 27001 Gap Assessment (and longer term, the Risk Assessment that is integral to ISO 27001).  Where attestation requirements are a bit higher, we often supplement the VA/PT results with a Security Data Flow Diagram (SDFD) depicting key security treatments throughout your client's data-lifecycle.  The SDFD is also leveraged during the ISO 27001 Risk Assessment phase.

Please call me on my cell (732) 267-6324 when you have a few minutes to discuss this further.

PS: You might also want to check out our ISO 27001 Case Study and other ISO 27001 resources for further information! 

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