Operational Security for Non-Techies

Friday, September 17, 2010

Jamie Adams

4085079c6fe0be2fd371ddbac0c3e7db

There are an abundance of technologies which focus on security while other technologies have security features built into them. It can be overwhelming choosing the right technology to meet your security requirements.

Yet, any technology would be rendered useless without operational security. Incorrect implementations, misconfiguration, poor procedures, lack of contingency plans, untrained or undisciplined personnel all contribute to poor operational security.

Last year, a friend of mine was in the planning phase of expanding their business by harnessing the power of electronic commerce — selling their products over the Internet. The business, Adeler Jewlers, is highly reputable and the kind of business which believes today’s quality is tomorrow’s customers.

They had concerns that poor online security could jeopardize their customer’s financial information they’ve been entrusted to protect. They hand-craft works of art worn by celebrities and everyday people — but they know nothing of system availability, electronically ensuring confidentiality, or ensuring data integrity. After all, they’re gifted artisans and gemologists not techno-geeks.

They were planning to use a service provider which specialized in electronic commerce. Prior to interviewing the service provider, they asked me for advice and to suggest interview questions because I have many years of experience working in secure operational environments.

My first inclination was to ramble on about high-availability, data integrity, patch management but I stopped before I blurted out my first geek word. Instead I discussed it in terms of how operational security impacts their business.

If a system is unavailable, you lose business because customers can’t use your website. Now I was speaking this business woman’s language. In the end, she found a service provider that answered her questions and met her very high standards of customer care.

More recently, my company’s Security Blanket® customer base is expanding into various industries. These customers range in size, available resources, and experience but all share a common goal of protecting their systems. Some of these customers are venturing into new areas — faced with new security policies and requirements which they’ll address themselves.

Whether you’re like my friend’s business who will be using a third-party or you will be implementing the operational security yourself, I’ve put together some information to help you on your new venture — or should I say adventure?

Defining the Security Policy

A policy is high-level and defines what is required to protect your assets and ensure business continuity. Its constraints are typically legal in nature (e.g., Privacy Act of 1947, HIPPA, or FISMA). Additional constraints can be those imposed by business objectives such as system availability and timely service.

Since my friend’s business was going to be involved with electronic commerce, I suggested to her that the service provider she chose be PCI DSS compliant.

The Payment Card Industry’s (PCI) Security Standards Council is an open global forum. Launched in 2006, it is responsible for the development, management, education, and awareness of the PCI Security Standards, including the Data Security Standard (DSS).

Not technically a policy; it is however, a requirement set forth by the Payment Card Industry if you want to do business with their card holders online.

Questions:

  • Depending on your business, what kind of certifications does the service provider possess? If you’re deploying an electronic commerce solution, ask to see evidence of their annual PCI DSS assessment. Typically, providers are certified annually but undergo quarterly assessments to ensure they are maintaining the appropriate level of security. If the service provider says they perform self-assessments, then I would ask how often they perform them and to provide evidence that they were in fact performed — but that’s just me. (PCI DSS § 12.1.2 & 12.1.3)
  • Personnel — What is the service provider’s hiring policy? What kind of system administrators will be managing your customer’s information? These people have access to your customer’s information and will be an extension of your business so their actions reflect your business. (PCI DSS § 12.7)
The Architecture

The architecture must be clearly documented. For organizations responsible for their own operational security, it is imperative that you document the architecture and routinely update it. I’ve always said that “...the existence of quality documentation separates the men from the boys.” Besides, you can’t securely manage assets if you don’t know they exist or how they’re expected to function.

Service providers adhering to the PCI DSS are required to submit a Report On Compliance (ROC) which includes architectural diagrams.

However, it is highly unlikely they would divulge these diagrams to their customers and I wouldn’t expect them to for security’s sake. Which is fine because most of their customers wouldn’t understand what they meant anyhow.

Nonetheless, as a potential customer you can still ask them questions about their architecture such as redundancy characteristics which facilitate the continuity of your business in the event of failures or disasters.

Questions:

  • What kind of physical security is in place? Is the room in which the system hosting your applications restricted? Are only authorized personnel allowed access to your systems? (PCI DSS § 9)
  • Is the level of service to be provided clearly understood? Does the architecture allow the system to be available to customers 99.999% of the time? If the service provider does not meet the agreed upon level of service, how are you compensated for potential loss of business?
Plans & Procedures

In the real world, would you board an aircraft for a transatlantic flight if you knew neither the pilot or maintenance crew performed their pre-flight checklists? Of course not!

Plans help enforce your policy while procedures are typically part of your plans. While there are many plans, one of the most important is the Business Continuity Plan (BCP). In the old days, we called them Disaster Recovery Plans but with today’s technology and the right architecture, you can continue business despite a disaster. Hence, the term continuity.

An Incident Response Plan should also be in place in the event of a system breach. If customer card holder information is compromised, the incident response plan is to be implemented immediately.

Questions:

  • Are media back-ups stored in a secure location, preferably an off-site facility, such as an alternate or back-up site, or a commercial storage facility? How is the media transported? How is older media destroyed? (PCI DSS § 9.5 – 9.10)
  • Is there an incident response plan in place? Is the plan tested routinely? How are card holders informed if there was an incident? (PCI DSS § 11 & 12.9.1)
Configuring & Maintaining the Systems

Configuring systems for production use involves allocating hardware (or more commonly in today’s Green IT environments — provisioning virtualized guests), installing operating systems, configuring the applications, and certifying them for use.

Configuring operating systems consistently, in accordance with security guidelines, is where Security Blanket® excels. Our customers, which include service providers, as well as organizations configuring their own systems to be PCI DSS compliant, consider Security Blanket® invaluable.

As a matter of fact, a customer recently stated “...I just completed in 8 minutes what I have been working on for the last several weeks.”

I recently wrote an article describing the activities required by system administrators to become PCI DSS compliant — check out “PCI DSS from a Linux Sysadmin’s Perspective”.

Once the systems are configured and tested, they should be baselined. This is essentially a snapshot of how the system is configured which can be used to compare against a future snapshot to identify any changes to the system. Identifying changes is an invaluable forensics tool for use in Incident Response Plans as well as evidence for change management processes.

If you’re researching a potential service provider, these activities are really under the hood and wouldn’t be of much interest to you. However, I would ask a few questions regarding provisioning and how your customer information co-exists with their other customers.

Questions:

  • When they provision resources for new customers, is it disruptive to your systems? If your systems become slow, how easily can they provision additional resources to your configuration?
  • In situations where your customer information co-exists with another business’s customers, to what degree is that information isolated or contained?
Managing Change

Operational systems must have the characteristic of being changeable. They must be able to adapt to new security guidelines, new architectural components, upgraded or replaced technology, and growth due to increased demands on the system.

“Change Management is an IT Service Management discipline. The objective of Change Management in this context is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to controlled IT infrastructure, in order to minimize the number and impact of any related incidents upon service.”[Wikipedia]

Changes are inevitable but the associated risk must be mitigated. For example, consider that new versions of software are always being released. These new versions might include new features or they fix vulnerabilities. What is riskier: running a vulnerable version of software and risk being attacked or upgrading the software to eliminate the vulnerability? Most logical people would choose to upgrade. However, it is imperative that this new version of software be thoroughly tested in an environment which mimics production to ensure the “fix” didn’t break other features. This process of updating software is often referred to as patch management.

Questions:

  • How do they ensure your systems are protected with the latest patches? When they apply patches, will your systems continue to be available? (PCI DSS § 6.1)
  • Are all new software updates (patches) thoroughly tested prior to deployment into production? (PCI DSS § 6.3.1)
Summary

Regardless of whether you’re responsible for your own systems or you’ve entrusted someone else, operational security is critical. Even the latest and greatest most sophisticated technology could be hindered or worse, rendered useless, if poor operational security exists.

In my opinion, the number one ingredient to operational security is trained, disciplined personnel. They need the right tools which empower them rather than over complicate their already stressful jobs.

Cross-posted from Security Blanket Technical Blog
Possibly Related Articles:
16099
Enterprise Security
Information Security
Security Management
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.

Most Liked