Engaging a third party to manage the controls, monitoring, and maintenance that secure a company's most important data assets can seem counter to the security of that data. I would venture that the opposite is actually true.

The employees a company hires are typically selected and trained for their productive abilities that have little to do with securing data. Even in IT, the technicians are judged first on their technology know-how and project experience, while security knowledge is either not considered or to be gained after hire, if at all.

Employees are selected and rewarded based on a "productive mindset" to achieve goals in the quickest and most effective method available, especially when teams are small and bringing innovative products to market quickly is the main goal. This mindset tends to disregard, or at least, fails to account for security and compliance measures. Teaching and instilling the practices required to obtain a "security mindset" takes time and resources, which are rarely available nor quickly obtained. For example, a productivity-based team can successfully bring an online product and e-store to market quickly, but would it also manage regular server updates and management of a web application firewall to protect the underlying systems? Probably not and understandably; it is not their expertise and anyone who has spent time in IT security consulting can confirm that a poorly executed or non-existent security program is as close as the nearest business.

Because of these issues, engaging with an external data security management service becomes a responsible business management decision. Handing the various security controls, audits, monitoring and patching to people trained for the purpose and with a "security mindset" allows companies to concentrate their talent where it is needed...building better products. And when the company is innovative, requiring agile thinkers using fast development models, taking advantage of the built-in security practices provided by a managed data security provider allows it to maximize the positive aspects of that model, while reducing the security risks imposed by it.

Further Reading

Security in a Reputation Economy - Bruce Schneier

Coming up next week is the annual PCI Community Meeting in sunny Las Vegas, and we hope to see you there! With many years of solid security experience under our belt, we have many exciting things to share with you about security and how we help companies big and small achieve and maintain PCI DSS compliance. So please take a moment to stop by the GSI booth on Wednesday, September 23, to visit with us. You'll walk away knowing the facts about what an experienced compliant services provider can and should be able to do for you.

Please see details about the event here:
https://www.pcisecuritystandards.org/news_events/community_meeting_09.shtml

We look forward to meeting you!

There has been a lot of commentary about terrorism over the past few years. Since 2001, we've seen the word "terrorism" overused, misapplied, with over reactions to it. Well, get ready for the same reaction to the next buzzword: Cyberterrorism. Already, Congress is preparing laws that will provide strong security for our nation's SCADA systems -- something that has left many people saying, "What's SCADA?"

SCADA stands for Supervisory Control and Data Acquisition. Your local water purification and power plants use SCADA devices to monitor levels, control valves and switches, and alert to dangerous conditions. However, just as the SCADA devices can be remotely controlled, they can be remotely abused. There was an incident in Australia seven years ago where raw sewage was dumped into the water supply by a disgruntled employee via remote control. Vendors have just now gotten around to providing HTTPS as an optional add-on!

Most SCADA systems are designed to be operated in a fairly secure environment. For smaller operations with only a single building's worth of systems to worry about, security is not an unreasonable expectation. Locations with a single building can easily have a secure perimeter locked down from physical access. For larger suppliers, such as power plants with substations and oil companies with far-flung pipelines and valves, remote security is much more of an issue.

Of particular concern to me is the growing trend of SCADA systems using increasing numbers of remote systems for monitoring. Many electricity suppliers are using these systems in power meters for billing and the ability to shut on or off power to residential buildings on demand. We've already found out recently how WPA is insecure. How many wireless SCADA systems do you think still use WEP?

There are many secure SCADA implementations out there, but most of those belong to large companies that can afford to hire not just system administrators, but dedicated security professionals as well. Many suppliers -- particularly ones that serve rural areas -- don't have those resources to draw upon. For them, managed co-location services can provide serious benefits. By using an existing network infrastructure, secured with encryption, auditing, and policies strong enough to protect financial data, these suppliers can be sure that even far-flung servers are secured, and get back to their business -- supporting our nation's critical needs.

Are you a skeptic in your passion for all things cloudy? Companies buying and selling cloud-based services have had to deal with an attitude shift to "where is my data?" fear and loathing. This angst is understandable, especially when protecting data that can make or break your company's reputation, business transactions, or even worse, data that potentially belongs to your clients.

GSI's complex managed hosting and PCI-DSS compliant hosting clients simply wouldn't/couldn't fathom not knowing where the bits live, and EXACTLY how we were protecting them, feeding them and watching over them every minute of every day. We went for true enterprise virtualization when we built our Matrix virtualization/cloud offering. Tools like VMWare Enterprise, NetApp Storage, Cisco and Force10 Networking, Dell/AMD Servers, etc., have proven themselves over and over again both in our shop and in nearly every IT organization we meet.

If one of our clients wants to know where their data is, we can point it out, both logically and physically. We can explain the security protocols, lockdowns, and testing that is performed to ensure the integrity of their data. We show them our PCI-DSS audit of our Matrix Virtualization platform and enable them to sleep at night knowing that the cloud won't "swallow" their corporate or client data.

We wanted to make sure that our cloud was anything but secret sauce. It's mustard, ketchup and some pickle relish (actually Enterprise Pickle Relish 2.1c).

<analogy alert> I see hosting in the cloud a bit like taking my eight-year-old niece and nephew on a trip to the mall. Most cloud offerings would say, "Go ahead, just drop them off and let them run around our semi-structured environment." Well, besides that fact that there are occasionally a few undesirable people at the mall, I just don't trust that my precious assets will be safe. When I ask for details and get "non-specific" answers on their security, activities, whereabouts and planned activities, I am definitely not going to let them have the run of the place.

However, I have no problem dropping them off at their school, because I know there is a structured security plan, trained professionals that cater to their needs, and at any time, if I need to, I can identify where they are and who they are playing with at recess.

GSI has been offering PCI-DSS compliant virtual machines for a couple of years already. We started by virtualizing environments for individual clients, and in January 2009, we announced our Matrix Virtualization platform, which has been fully validated as part of both our SAS70-Type II and PCI-DSS compliance assessments (yes, we are a PCI-DSS Level 1 Service Provider). PCI in the cloud can be done, and is being done.

Further Reading

GSI's Matrix Virtualization Platform

In my three-part discussion on change management, I've covered its importance as a formalized strategy, and how to deal with security event volume. This last section will briefly touch on the role of change management in identifying unauthorized change.

The value of this capability for risk control is very high. A single case of file change without a corresponding change authorization can highlight troubling issues and generate activities in relation to them.

Scenarios that generate unauthorized change events are numerous.  Is it a policy breach where someone neglected change management? Then education is applied. Has an attacker modified a vulnerable web site? Then an incident response plan is engaged and protection put in place.

The same model works for other security software, as well. Intrusion detection systems (IDS) are notorious for being event generators. Being able to match IDS events to a recent change drastically reduces the investigation time.  An example could be the installation of a new product that includes a browser "help" bar, which is also spyware. This example would generate both IDS and anti-spyware alerts, both of which would be matched back to the approved installation of new software. The administrator working the event can use this information to directly address the issue.

Change management is classically an operational tool for preventing system outage. It should also be well-respected by the savvy security professional as another tool for reducing risk and acting as a force multiplier.

Further Reading

Change Management: A Hidden Security Tool - Part 1 of 3
Change Management: Event Volume - Part 2 of 3

In my first article, I introduced how companies can benefit from a formalized change management strategy. This week, I want to talk about a second important factor related to change management – dealing with security event volume.

Every serious information security wonk understands that security software can generate large numbers of events. The volume can be staggering with just a few systems, and for each increase in the number of systems, the event volume grows exponentially.

Logins, object access, file changes, internet attacks, virus alerts and intrusion detection events can have the combined effect of disabling a security team's capability to detect risk. Highly secure or compliant environments could easily require a security staff similar in size to operational teams just to control risk while providing for regulatory compliance. GSI takes a delegated approach.

It turns out that most data center operational teams have significant amounts of down time. GSI is more than just a data center operator; we are more of a secure data systems management company that happens to run a few data centers. Even so, the operations staff still has floating downtime when all they do is monitor system status. So I use that time for security events.

Every operations member is obsessively focused on our support ticketing system and rightly so. It is the primary mechanism for supporting our clients. Additionally, operations must respond and address every support ticket within time limits to meet service level agreements. It turns out that if I can put security tool events into the support system and provide specific instructions, then my capability to work events is equal to that of a security team the size of operations. A discussion of the need to engage an entire IT staff in security functions is not for this posting, but you get the idea.

So we have our security software events and we have a staff of folks to review and work them. How does change management affect how the events are worked?

The easiest example to explain is File Integrity Monitoring (FIM). GSI currently uses TripWire for FIM to detect changes in files deemed critical for risk control. The file list is long and amounts to operating system files, configuration files and website source files. A single MS patch cycle can generate thousands of events across hundreds of servers at once.

We use our change management system to track and approve patches to systems. Before the first file change occurs, the change management team will review and record approval for it to happen. When the FIM system generates alerts about file changes directly into the support ticket system, any team member on duty can check for "approved" changes associated with the affected system. A positive identification of authorized change stops the investigation with no more time dedicated to the issue. More poignant, for security at least, is that an unauthorized change is just as quickly identified. Stay tuned for next week's posting, when I talk about the value of change management in identifying unauthorized changes.

Further Reading

Change Management: A Hidden Security Tool - Part 1 of 3
Change Management: Identifying Unauthorized Changes - Part 3 of 3