Look around you – from an information security perspective things are getting very interesting.  Laws and regulation are expanding, geopolitical hacking is commonplace, information privacy – or the lack thereof – is a persistent discussion from Congress to the coffee shop, identity theft is an accepted risk we now have insurance for, digital espionage is old hat, hackers are sophisticated and highly organized – and virtually impossible to stop –and the threat of cyberwar looms. 

The mere thought of these topics was enough to scare CEOs into buying newfangled firewalls in the early 1990s, but did we actually think we’d be wading neck-deep in the issues we’d only speculated about twenty years ago?

As these ideas have come to fruition, there are new threats now and I’m confident things are only going to get more interesting in the next decade.  And this makes the job of the future whitehat hacker a most fascinating one. 

Let’s take a quick stroll down memory lane to a time when the Internet was not much more than animated GIFs, security was G3 – guns, gates, guards –and there were few regulations.  For those companies dipping their toes into the ether, security was a distant concern.  For most, the promise of opportunity on the Internet exceeded any concerns about the poorly understood threat.  Promoting the need for security was based on speculative arguments, worst case scenarios, and other “what if’s” that fell on deaf ears.  As a result, security-minded folks saw an opportunity and invented penetration testing.  In short, pen testing was based on the concept if they didn’t think it was possible, we’ll prove it.  And, it’s been pretty much that way ever since.

Then came regulations, such as HIPAA and GLBA, that started to tap into the concept of security and the value of information in the late 1990s.  Alongside was the introduction of security standards, most notably BS-7799, which is the grandpa of the big ones today – the 27000 series.  During this time ethical hacking experienced a lull … a form of commoditization.  Tools flooded the market to perform automated scanning and the concept became simply a part of the security program.

As we moved into the 21st Century, ethical hacking became organized.  Groups formed in consulting companies that employed only skilled testers, provided them with tools and methods, and kept them together, focused on a single aspect of security.  As businesses matured, so did the testing process.  Application testing became a specific part of testing, OWASP evolved from a few smart guys to a global community of smart guys and the foundation of many base requirements.  Finding vulnerabilities and exploiting them to determine potential impact and risk seemed to be reaching a zenith.

However, the art of penetration testing didn’t stop developing under the umbrella of conformity and business cards.  Mostly because whitehats, at least the really good ones, have blackhat DNA.  It’s in their blood to keep pushing.  This ushered in reverse engineering malware, researching vulnerabilities, targeted tools development and experimentation in new technologies.  Of course, the gears of commerce kept turning and we also experienced a rush of training and certification.  Tools to help newbies do what only the best could do a year before, downloadable hacking platforms like BackTrack, turned every techo-weenie into a whitehat overnight.

So, what we have is a security environment where the ability to peer down the rabbit hole, think like a hacker and pull apart systems to expose vulnerabilities is growing in importance and scale. 

In Part II of this series, I will highlight the three different types of whitehats and provide perspective on the really good ones. 

If you are interested in more on ethical hacking and specifically, its impact on the financial industry, please join us on Sept.  28, 2010, for a webinar.  RSVP for the event at: www.BTGlobalEvents.com/events/diaryofahackerwebinar.

Just when we thought we’d seen everything, Intel’s bombshell announcement that they are acquiring McAfee stands to shake up the security industry all over again.  Aside from the potential impact on the security vendor space (as far as all the downstream corporate customers are concerned), it’s interesting to imagine the alignment issues which will surely arise between these two massively security-conscious firms.

As a security officer, should you invest significant effort into building a set of practices and policies which somehow enable integration with a completely different set?  For example, at the easy end of the scale, you might have two different standards for how many failed logins trigger an account lockout, so you reconcile the two and come up with a new standard which everybody is meant to adopt.  Far more difficult are issues to do with internal failures and when/how they might ultimately require documentation in SEC filings. 

The security officer’s role in such negotiations is likely to be much less technical and more financial – building models to track costs, measure risk exposures, and the like – and the output from such efforts will probably end up on the desks of Legal and Accounting more so than IT or Operations.  Ultimately the decisions surrounding how to combine policies will be driven by business and risk considerations, first and foremost, but it’s a dangerous path for the acquiring firm simply to say the target firm shall inherit all the parent’s policies. 

This is primarily because the policies in place are usually a function of all sorts of local contextual issues, which are then mapped against whatever subset of industry best practices make sense for the business in question.  For example, if a development team is distributed globally while working on a single project, a firm needs to make a decision about using private WANs for data exchange, or instead, relying on local internet access at each facility and coupling that with a strong VPN.  If the immutable policy point at the acquiring firm says that no internal R&D data shall traverse the internet — and it was never written to consider whether VPNs are an acceptable carve-out — then the disruptive effect might be significant for all the IT and network teams which have to scramble to catch up. 

As with most things, there is no simple answer – the point is to ensure that M&A activities don’t simply assume “the IT stuff will sort itself out.”  The integration teams need to give an equal seat at the table to the security officer, the IT architect and whoever else is responsible for the glue that drives how the firms get things done behind the scenes.  It’s not just about operating synergies and reduced cost of sales anymore.

The summer heat waves are hopefully behind us, and the kids are starting to make their way back to school.  Do you remember those days?  The first lessons of the year are always occupied by new teachers doing a quick refresher to make sure the students are familiar with the necessary material.

As such, it’s a good idea to revisit the basics of information security and, specifically, what we know about the most common source of trouble — insider threats.  And it’s important to remember one crucial lesson — not all insider threats are malicious.  Most are, in fact, accidental.  A quick review of our “Confirmed Kill” data shows that more than 70% of such events that originated from inside customer networks were ultimately due to individuals trying to do the right thing, but falling afoul of policy, acceptable use restrictions, or change control windows. 

The tricky part of this is that, since these incidents aren’t running exploits, or allowing malware to propagate, or otherwise doing something which looks inherently dangerous, signature-based tools are unlikely to have anything to say about them.  Yet if someone, using valid credentials, from an authorized source, happens to make a temporary change to a firewall rule or an ACL on a database, and then forgets to remove it, there is a potentially huge exposure created entirely by accident.  The risk calculation from these insider threats is therefore largely about what might happen next.

The best solution is to couple behavior-based anomaly detection with a monitoring program which is able to incorporate normal activities and escalate them against contextual policy requirements.  If you have a rigid change control window for certain types of activities, and they are observed outside of that window, then you still need to know about the configuration changes, even if they are done correctly by authorized users.  If you don’t have such rigid controls, but your work patterns tend to cluster around common sources or timeframes, a behavior-based system can generate a reasonable profile of “normal” activity and still raise a flag if something appears to deviate.

What about if you’re a global business, with activity happening all the time, from sources all over the world?  Consider that you can still differentiate by internal subnets, or groups of usernames, or other logical groupings, even while everyone works within a single policy framework.  Your monitoring controls therefore should be architected to be able to observe data which is logically consistent with your internal groupings.  This gives you greater flexibility to tolerate different applications of policy without forcing a global team to jump through too many hoops.

Let us know in the comments if you’ve stumbled upon other considerations or techniques, and if you’d like someone to contact you to discuss your particular organizational needs down these lines — we’d be happy to talk with you.

It is no surprise that mobile device security is becoming a growing concern for CSOs everywhere. Although mobile phones have been part of many companies’ communications strategy for quite some time, what has changed significantly in the last few years is the substantial increase in mobile device sophistication and emergence of targeted threats – both seemingly outpacing comprehensive and effective security measures.

Today’s mobile devices are exponentially more powerful and complex than those from a few years ago.  This combined with increases in inexpensive bandwidth and millions of available applications mean more people are using them for more complex tasks, which include a vast array of corporate information and application interactions. The opportunity to lose valuable data or expose corporate systems to unauthorized access has been considerably amplified.

Although there are some evolving security solutions emerging in the industry to address mobile device security, not all are comprehensive nor can they be referred to as “enterprise-ready.” Moreover, many large organizations may have as many as a dozen different mobile device platforms being used that represent a broad spectrum of diversity, further complicating meaningful security. Also, given today’s device capabilities, it is difficult to determine if a user is retrieving email, files or accessing applications from a computer or an unapproved mobile device.

Of course, all this is exacerbated by threats that specifically target mobile devices. Hackers are attracted to mobile devices because of the diversity of attack vectors and opportunity.  These fall into three basic categories:

• Access to information – There are numerous applications that promote mobile online banking, social networking, and, of course, files and e-mail stored on the device, all of which represent value to a hacker.  Moreover, many mobile devices are VPN-capable, which can open internal systems to undesirable interactions.
• Toll fraud – Hackers have produced several Trojans inserted in downloadable games and applications that surreptitiously dial international premium rate numbers that produce revenue for the hacker. Additionally, there are malware that permit eavesdropping and other forms of man-in-the-middle attacks.
• Leverage – An emerging condition is where hackers are implementing root kits and other forms of malware that are essentially creating a botnet within the mobile domain, which can be used for a number of purposes, such as DDoS and SMS spam.

Concerns about the exposure of private information and communications is very real. In fact, just in the last few weeks, the U.A.E. has sought to block Blackberry messaging and e-mail, and the German government, which has advised officials not to use Blackberry and iPhone devices due to a dramatic increase of attacks and fear of snooping, is advising civil servants to use Simko2 by T-Systems.  And unfortunately, it’s likely to get worse before it gets better.

So, what can you do?

First, focus on the basics: policy, access control, monitoring, and education. Try to minimize platform diversity within the organization, but this is far easier said than done. Seek mobile device encryption solutions — a lot of data loss can be attributed to simply users misplacing their phones. There are some good anti-virus solutions on the market that should be reviewed and tested; however, you may find you need more than one solution.

Lastly, use mobile device sophistication to your advantage!  Produce corporate applications to help employees — even something as simple as an app that provides updated mobile security policies employees can reference, or access to approved software, or something that can help identify the device as it accesses corporate systems, such as certificates, or a proxy app to route Internet traffic through dedicated security systems under your control.

Anything is better than nothing.  Use the same capabilities that are at the disposal of hackers to do harm, but do good.  You may not get ahead of the curve, but at least you can start leveling the battlefield.

In the previous two posts, we discussed the reuse of malware and host recidivism.  In this article, we will focus on how pirated software is making the problem all the worse [piracy proportional to botnet size].

While there are many reasons for unsecure configurations, one of the most compelling reasons has to do with using unlicensed — and hence — unsupported software.  Yet I don’t believe it would be an overgeneralization to say that those running pirated software are not overly concerned with the confidentiality and integrity of their systems — at least, not as concerned as they are about the licensing cost of those systems.  While this is less of a threat to assets residing in a reputable enterprise environment, it is still a compounding issue that grows the ranks of botnets and adds amplification to DDoS attacks. 

Most sites offering pirated media and cracked applications are vertically integrated with organized crime-owned botnets.  The re-up process (marginal node = marginal $) is partially funded by recruiting unwitting visitors and asking for a virtual handout.  Perhaps it is Lady Gaga today, instead of Britney Spears of 1998 — whatever the reason or taste, the content will be offered, loaded with the same core seed – it will compromise the system that downloads it, have that system phone home and put that system to work. 

Users unwilling to pay for licensed operating systems in the first place (or unsophisticated enough to know the difference) are more likely to download other pirated software.  In doing so, they are positioning an inferior OS (one that has not been patched or even configured prudently) directly in contact with malware-laden content.  Often this is audio and visual media – formats in which myriad additional root level exploits exist.

It is difficult to even fathom how many instances of pirated Windows XP are online.  Despite Microsoft’s attempt at an amnesty program three years ago, it is doubtful there has been much reduction in percentage, let alone total number, as of today.  Some estimates quote as high as 40% of worldwide software is being pirated.  Of the counterpoints listed in this blog against RIAA and enforcement of IP statutes, not a single argument attempts to refute that installing pirated software on a system diminishes its security posture.  Perhaps the most ludicrous argument for removal of IP enforcement would be that piracy is “safe” for the user and the internet at large. 

To move to a technical direction — if the argument that security and piracy aren’t compatible at an application layer (e.g., sharing pirated DVDs via P2P software), it would even be more ludicrous to make it at the Operating System layer.  If the OS is counterfeit — either not eligible or the user is in fear of receiving security updates — there is little chance that it will remain a sovereign host.  Once compromised, there is much more of a chance that that the keyboard user (to contrast from the remote r00t user) cannot regain control and hence will be unable to restore the ability to update the host.  Even if the system owner wishes to legitimately restore state to a time prior to infestation, it’s often impossible.  Most of the Trojan software installed on compromised systems today either poison DNS such that the infected computer is browsing to a non-security site, or it injects itself somewhere in the process of the host trying to patch the OS or load current definitions into the A/V application.  Once compromised, access to the handful of sites that could offer the user assistance in cleaning up the rootkit isn’t possible without strong technical skills or intervention of a third party. 

Here, recidivism is made worse because an initially compromised system will continue to prevent updates and A/V software from being updated, even if the botmasters are behind bars, the C&C nodes have been turned dark, and the user wants to turn over a new leaf and pay for a legitimate OS license key.

For the reasons above, the botnet problem is not getting any better.  The resurgence of Storm/Kraken can be chalked up to reuse of code within isometric parameters where their ancestors existed.  The confusion over the name of which botnet has conscripted which node when is much less important than addressing the underlying environmental conditions that allow the continued presence of 10^8 node botnets driven by kids with learner permits.  

As a parting allegory — the illusion of IT progress was shattered several years ago when the Conficker botnet spread through LANs in the same manner as the Sasser worm (leading to Bobax and eventually Kraken).  Today, the Stuxnet Trojan is spreading to systems riding on the same USB drives that Conficker.C did more than a year back (remember past cries to disable autorun?). 

The more the security world changes, the more it stays insane!

For more information, please visit:

• Original Kraken [Damballa, Royal]: http://www.darkreading.com/security/perimeter/showArticle.jhtml?articleID=211201307
• Current Kraken [Damballa, Royal]: http://www.darkreading.com/vulnerability_management/security/antivirus/showArticle.jhtml?articleID=225701438&cid=RSSfeed_DR_News
• Original Storm [F-Secure Video and Commentary]: http://www.youtube.com/watch?v=kH8cS1AkqiI
• Current Storm [Felix Leder]: https://www.honeynet.org/node/539
• Mariposa Demise; Technical Ability of Mariposa Botmasters [Panda, Defence]: http://www.pandasecurity.com/homeusers/media/press-releases/viewnews?noticia=10085

To read the full paper on Kraken, click here. 

In yesterday’s post, we discussed the reuse of malware. In today’s article, I want to focus on how botnet “breaking” is effectively a zero-sum gain, as most nodes previously rendered benign by DNS sinkholing have rejoined some other botnets [host recidivism].

The sophistication of the botmasters pales in comparison with the persistence of the problem.  An owner unable or unwilling to secure these hosts affords their systems to be cyber-magnetically drawn into some future botnet.  Call it magic or fate — no compromised system just sits there and serves up the connected monitor web advertisements for timeshares and Viagra, without simultaneously offering other services to a Botmaster.  Just because a host has not been engaged in a SPAM campaign or doesn’t have an active keystroke logger installed doesn’t mean that the ability is not resident within the rootkit installed.  In today’s market, ignoring bot earning potential is akin to leaving money on the table, from an organized crime point-of-view. 

A system not patched against MS09-123 is likely not going to be patched against MS10-123.  This is primarily because the decision to patch is most typically made by implementing and enforcing a policy that stipulates the process of perpetual patching for the lifecycle of that piece of software.  The merits of an individual patch and the situational risks surrounding the vulnerability at hand are less likely to come into play since so much software needs patching so frequently.  Modes of interaction of a vulnerability in a distinct piece of software cannot always be anticipated because the instantiations of that vulnerability (no matter how minor) in custom configurations and interactions with other objects are too numerous to fathom. 

End users are not typically engaged in formal policy adherence to their home systems — that is not the claim here.  However, the principle carries forward as those end users who roughly follow a best practice configuration seek out and engage offering by the specific vendors they use, most notably the automated processes allowing for silent and automatic patching of the software.  Whether the software belongs to Adobe, Microsoft or Apple, most major vendors offer means for systems online to update themselves before or shortly after vulnerable binaries are executed by the user. 

These (and formally documented) processes are made for repeatability.  So a missed patch is rarely as much as an oversight as it is another in a pattern of computer activity (really, lack thereof) that’s put into motion by actions that the responsible party made at the original installation of the software, up to and including the OS installed on that host. 

An example shown in a 2008 Computerworld article (“Update: Two-thirds of Oracle DBAs don’t apply security patches” [1/14/08]):

“The results, which come even as Oracle is scheduled to release its next batch of quarterly Critical Patch Updates tomorrow, showed that 206 out of the 305 surveyed said they had never applied any Oracle CPUs.  Just 31 said they had installed the most recent security update from the company.  In total, only one-third said they had ever installed an Oracle CPU.” 

Considering this survey deals with administrators who are skilled in technology, but may be fearful of uptime consequence by introducing the patch, it doesn’t bode well for end users who feel ambivalent towards their responsibility to update their systems.  Whether the cause of the updated state erosion is active or passive, recidivism is high for all of these hosts.

To read the full paper on Kraken, click here. 

Last month, we posted an article on the return of the Kraken botnet.  In addition to Kraken, the Storm botnets have also made a slight comeback on hosts once belonging to the recently decimated Mariposa Botnet.  Over the next several days, we will examine the technical issues surrounding the return of these botnets, with a focus on the following areas:

• The reuse of malware by persons of less technical sophistication than the original authors [lowering barriers to field entry]
• That botnet “breaking” is effectively a zero-sum gain, as most nodes previously rendered benign by DNS sinkholing have rejoined some other botnet [host recidivism]
• Pirated software is making the problem all the worse [piracy proportional to botnet size]

In this commentary, we’re covering the first area since there is plenty of evidence to support the claim that people of less technical sophistication than the original authors are reusing the malware.  Consider the attestation of Panda Security’s Pedro Bustamante:

“Our preliminary analysis indicates that the botmasters did not have advanced hacking skills.  This is very alarming because it proves how sophisticated and effective malware distribution software has become, empowering relatively unskilled cyber criminals to inflict major damage and financial loss.”

If the case were that Mariposa was a low tier botnet (say only 100,000 nodes), perhaps it could be explained away that script kiddy botmasters got lucky for a while.  They inherited well, or knew the “right people” in lieu of the “right stuff.”  However, this was not the case.  Mariposa was a 10^8 node botnet, and that, by any estimation, is a really big number. 

The position of the botmasters being N stages removed from the original authors supports the arguments that a botnet in itself is mercenarily a commodity.  To compare, entities that own the most barrels of petroleum at any given time are neither producing nor consuming petroleum.  They are “possessing it” in an assumption of risk (and hence profit) that comes from stewardship between the time it is made available and the time it is consumed by a refinery.  They don’t need to know details of either the production or distillation of the content, and they have no special skills (or at least display none) in either area.  This is similar to why these botmasters don’t need the same technical abilities that the authors of the original code exhibited.  Would a case be heard where the writer of Trojan software would sue a botmasters for financial loss or defamation??

It would be difficult to defend this position if Mariposa was not the single biggest documented botnet in the world back in January.  As skeptical as we are about actual numbers of nodes reported as participating in a single botnet — if the actual number was only 1/100 of the touted  number (which would be one hundred-thousand) — it would still be greater than the total number of computers in each of half the world’s countries.  Just consider that several people lacking technical sophistication, unaligned with any foreign government, were harnessing the power of a 3-gigawatt-per-hour computing center.*

   *  Calculations for emphasis only; assume 300W PSUs, 10 Million hosts online at a single time.

To read the full paper on Kraken, click here.

Michael Rasmussen, OCEG fellow and former analyst at Forrester Research, recently wrote a post on his blog regarding managing risk and compliance across business relationships.  Mike points to the fact that, “Organizations are complex entities that extend to hundreds or thousands of business relationships around the world.  Even the smallest organization can have diverse global business relationships.  The impact of the extended enterprise is significant for business.”

I completely agree.  Now, more than ever, organizations are striving to prevent the economic downfall resulting from too much risk acceptance.  Risk Management attempts to look at the people, processes, technologies, and external events that make up the accepted landscape of the organization.  Here is where omissions often occur.  Looking at the organization’s recovery plan does not include the risks inherent in your outsourcing partner’s operation.  At a higher level, what really is the best way to determine the true measurement of an organization’s risk?  How should the borders for risk be envisioned?

Develop a clear picture of the extended enterprise

The first step in managing risk is to know the organizations’ boundaries. The board or other governance group should have as clear as possible an understanding of what is “at risk” when discussing scope.  In a global economy, these boundaries are constantly in flux; and maintaining a clear picture of a company’s perimeters and extensions of those limits can be challenging.  And the challenge becomes more complicated if silo-thinking is a predominant part of corporate culture. 

Define the areas of change

It is often assumed that a business is functioning normally if the lights are still on and no new risks have been identified.  This is often a poor assumption and tied to a belief that the “organizational boundaries for risk management” stop at the door.  For multi-national corporations, in particular, what is happening on the other side of the world is just as critical to risk management as what is occurring in your backyard.  Short-sighted scoping may leave the officers of the company acting shocked and dismayed at the feasibility of something happening beyond the scope of the organization’s physical boundaries.  How many companies can take the public scrutiny of millions of observers when an incident comes into the hands of the media like recent oil spills?  If the risks aren’t being reviewed because the boundaries aren’t fully known or considered, too much is probably at risk.  Watch for “change” in the organization, for “change” is a trigger that signals ways new risk can creep into your organization.

Examine the types of risk and responsibility

There are general categories of risk to any business, and most risk managers will agree that besides operational risk management, there are also strategic, financial and compliance risks.  Operational risk does need to include both internal as well as external relationships.  It also includes a very close look at the values of your business partners when it comes to risk-taking.  Operational risk encompasses the “entire” organization.  If your organization’s appetite for risk is not the same as your business partner’s, expect to absorb the differences because that’s how risk-taking works.  Your options always include mitigation, in any form that your organization requires, to reach the desired level of risk acceptance.  A more forward-thinking approach is to let corporate social responsibility help guide the way to determining how compatible your marriage will be with a business partner, before you accept the risk.

The bottom line – most organizations need to view their organizational map more broadly than they currently do.  Risk management and risk appetite must be considered before engaging in a relationship of any sort.  Failure to do so could bring unwanted risk to your own organization.

Before I became a CSO, I thought the perfect night out was dinner and a movie.  Now, while I still like to see a good movie, the opportunity to get together with my peers and talk about issues at work — the ones that keep me up at night — beats any Hollywood blockbuster.

This Wednesday evening, July 28^th, I will be hosting a dinner for Chicago-area CSOs to talk about these very issues.  I know that I’m looking forward to finding out how others are dealing with risk management issues, success you are having with getting a seat at the boardroom table, how cloud computing is changing how you allocate security resources, and sharing my experiences and successes in protecting data and managing risk at a global level.

To register for the event, please contact Kurt Luporini, BT’s security specialist in the Chicago area.  If you’re not able to join me for dinner on Wednesday, why not connect with me on LinkedIn either directly or through the Security Leaders Group.

The National Security Agency recently unveiled a program to help secure the networks of crucial domestic infrastructure, including the networks of electrical companies and nuclear power plants. Called “Perfect Citizen,” the program is geared to bring attention to the possibility of grid hacking.

Interestingly, a recent Wired article asked, “…if it’s so easy to turn off the lights using your laptop, how come it doesn’t happen more often?”  According to the article (“Hacking the Electric Grid? You and What Army?” (July 13, 2010):

Your average power grid or drinking water system isn’t analogous to a PC or even to a corporate network. The complexity of such systems, and the use of proprietary operating systems and applications that are not readily available for study by your average hacker, make the development of exploits for any uncovered vulnerabilities much more difficult than using Metasploit.

To start, these systems are rarely connected directly to the public Internet. And that makes gaining access to grid-controlling networks a challenge for all but the most dedicated, motivated and skilled — nation-states, in other words.

Let’s pretend for a moment that hackers were planning to attack the U.S.  What would they need to do to gather enough information necessary to take out the electrical power in key parts of the country?  They don’t want to fiddle at the edges, mind you.  They want to have enough data to build the technical capability necessary to shut out the lights in Washington or New York or California at precisely the time and for exactly the duration they want.

For starters, they would need to know things like:  Where are the power plants?  What kind of plants are they? What sort of fuel do they use?  Who built them and when?  What sort of materials and technology were used when they were built?  Who manufactured the generators, turbines and other key equipment?  Whose SCADA software are they running?  Who runs the plants?  How does fuel, people, supplies get into or out of the plant? What sort of security do they have?  And perhaps most importantly: which plants supply power to which parts of the country?

While the Wired article included a lot of questions that are interesting, we ask: Are foreign attacks on our nation’s crucial infrastructure possible?  Our answer is absolutely. This is a real security threat and one that shouldn’t be taken lightly.

In fact, The New York Times reported last week that a new virus targets the computers used to manage large-scale industrial control systems used by manufacturing and utility companies. While the SCADA systems that run the software are not typically connected to the Internet, this specific virus spreads when an infected USB stick is inserted in the computer.

To assist these organizations, BT Managed Security Solutions Group offers a multi-layered, holistic approach to secure critical network infrastructure (CNI) and organizational monitoring. This offering enables any organization to have a view of its security posture as it relates to its critical infrastructure (substations, control centers, energy management systems) and its interconnectivity with the organization.

With a holistic approach, the footprints of an attack may be discovered across multiple systems or even across multiple operating areas.  As organizations merge to achieve economies of scale, disparate geographic operating regions become interconnected via common enterprise environments.  

In today’s regulatory-driven environment, an organization must consider its entire critical infrastructure – from the substation to the control center and out to the enterprise network – when making security monitoring decisions.

The fast and accurate detection of security-related events is an organization’s first line of defense against security intrusions.  This can only be achieved through a holistic solution that provides enterprise-wide security by aggregating and correlating information from both critical network infrastructure and enterprise networks, providing organizations transparency into their security posture.