Thursday, July 23, 2009

CyberSecurity: Why You Should Read This Book

Security standards promote managerial truths but don't help you get things done. Create processes. Manage risk. Get organized. Those ideas sound good, but what does the process look like? How do I do risk analysis? How do I organize my assets?

Vendors paint a confusing picture of what I need to buy - one tells me the opposite of another vendor.

"What do I do?" "What should I buy?" - Are you asking these questions?

This book provides you with a practical approach to IT security by providing a methodical way to view your IT infrastructure, identify/prioritize assets you should protect and ways to protect them.

If you want to gain a strong grasp of the basics of IT security and a "vendor-neutral" perspective on approaches to enhancing your security, this blog will help you. Don't buy products that vendors want you to buy - buy things that help your organization.

Part 1: Understanding the CyberSecurity Framework
Full Table of Contents
Terms of Use
The Purpose of This Book
Table of Contents
Part 1: Understanding the CyberSecurity Framework

Part 2: Security Measures

Part 3: Compliance

Final Words on CyberSecurity

Bookmark and Share

Final Words on CyberSecurity

I believe that the general principles of cybersecurity covered in this book will remain the same in the foreseeable future. The three security goals of safeguarding availability, integrity, and confidentiality probably won’t change. You will always have to worry about external users and internal users.

This book describes a way to identify security issues that apply to your organization and provides examples of potential security measures. I hope that this book helps IT professionals relate security measures to security issues. This book should help you avoid getting stuck on the details of security technologies, see the big picture, and assess how vendor technologies fit your needs.

It’s important to note that cybersecurity involves not just having technologies, but using technologies the right way. You can buy the most expensive firewall in the market, but if it is not configured correctly, then it is not enhancing security. You can buy the most expensive cybersecurity monitoring system, but it may be looking for the wrong things.

Doing cybersecurity “right” is challenging. Cybersecurity is not just a concern of IT professionals of your organization, but requires the participation of all members of your organization and partners who share your IT resources. It’s not just about technologies; it’s also about expertise.

No matter what compliance standard concerns your organization, I hope that this book gives you a starting point to begin a cybersecurity or compliance programs.

Bookmark and Share

23: Other Compliance Standards: SOX and NERC

The CyberSecurity Framework can be leveraged to better understand how to start the cybersecurity component of compliance. This article will focus on two more compliance standards, SOX and NERC, and relate them to parts 1 and 2 of this book. The point of this article is that the underlying security issues for different kinds of data and IT resources are largely the same although the data and assets of concern are different.

Sarbanes Oxley Section 404 - SOX
You can get a copy of the law here:

You can get more guidance from the SEC about SOX Section 404 for small businesses here:

SOX Section 404 requires adequacy of internal controls over financial reporting.

Auditors may check whether the data entered into the accounting system is true by performing an audit. If the company is depreciating assets, the auditor should check that the assets actually exist. If records show that 5,000 widgets were sold and delivered to Widgets R Us, then the auditor can check that 5,000 widgets were actually delivered to Widgets R Us. Auditors can check that the numbers being entered are real.

While auditors can ensure the entry of truthful data, the cybersecurity team can ensure the integrity of financial data by ensuring that the right people are entering the data and no data is being altered without the knowledge of the organization’s rightful authorities. So the cybersecurity measures boil down to safeguarding the integrity of financial data. You must also be able to present evidence that the security measures are working.

North American Electric Reliability Corporation - Critical Infrastructure Protection
You can get a copy of the Critical Infrastructure Protection [CIP] standard here:

This standard concerns itself with safeguarding the availability of the assets that support the “Bulk Electric System.” The assets to consider are listed in Standard CIP-002-10 Cyber Security – Critical Cyber Asset Identification R1, .

CIP includes the following sections:

  1. Sabotage Reporting
  2. Critical Cyber Asset Identification
  3. Security Management Controls
  4. Personnel and Training
  5. Electronic Security Perimeter(s)
  6. Physical Security of Critical Cyber Assets
  7. Systems Security Management
  8. Incident Reporting and Response Planning
  9. Recovery Plans for Critical Cyber Assets

The approach presented in part 2 of this book to safeguard the availability of assets can help you get a more concrete vision of the security measures you will implement.


You are probably now discovering that the underlying security issues for compliance standards, even ones not mentioned in this book, are similar. They boil down to safeguarding the availability, integrity, or confidentiality of your data or IT assets. Security measures that address the underlying issues can be similar although the specific data and IT assets of concern are different.

You must take measures to address security issues surrounding external and internal users. You must address security issues in the physical and logical spaces. You should have methods of continuously monitoring for potential security breaches and have some kind of reaction plan in store. Giving right people the right level of access control to critical/sensitive data and assets is always an issue.

Parts 1 and 2 of this book cover these common security issues and provide examples of security measures that address these issues. When the specifics of a compliance requirement are unclear, understanding the requirements in the context of the CyberSecurity Framework will help you better judge what security measures are appropriate, build an effective security program, and avoid taking each compliance requirement as boxes to check off a laundry list.

Next Article:
Final Words on CyberSecurity

Go to: Table of Contents

Bookmark and Share

22: HIPAA - Health Insurance Portability and Accountability Act

HIPAA was enacted in 1996. The “Security Rule” of Title II of the act describes security safeguards. The safeguards are categorized as:

  1. Administrative safeguards
  2. Physical safeguards
  3. Technical safeguards

Within the cybersecurity space, organizations are required to protect the availability, integrity and confidentiality of electronic forms of protected health information [PHI]. PHI on paper is also protected by HIPAA but in our cybersecurity space, we should concern ourselves with PHI in electronic form.

With an understanding of the CyberSecurity Framework and security measures, we are better fit to understand what to do about HIPAA for cybersecurity.

It is important to note that compliance to HIPAA requires other information technology measures. For instance, the “Transaction and Code Sets Rule” describes how data should be exchanged between different organizations. Furthermore, the Privacy Rule of HIPAA describes how PHI should be handled and these requirements may impact your information technology operations. These topics, however, will not be discussed in this article.

The Security Rule will be the focus of this article.

Where To Get Security Rule of Title II of HIPAA
The US Department of Health and Human Services website is here:

The final Security Rule (Feb. 20, 2003) is available here:

Please refer to “Subpart C – Security Standards for the Protection of Electronic Protected Health Information” of the document.

HIPAA’s Sensitive Information

The Security Rule applies to “covered entities” including health care plans, clearinghouses, and some providers.

HIPAA requires the following 18 types of sensitive patient data (From: Title 45 Code of Federal Regulations 164.514(b)(2)(i)

(A) Names;
(B) All geographic subdivisions smaller than a State, including street address, city, county, precinct, zip code, and their equivalent geocodes, except for the initial three digits of a zip code if, according to the current publicly available data from the Bureau of the Census:
(1) The geographic unit formed by combining all zip codes with the same three initial digits contains more than 20,000 people; and
(2) The initial three digits of a zip code for all such geographic units containing 20,000 or fewer people is changed to 000.
(C) All elements of dates (except year) for dates directly related to an individual, including birth date, admission date, discharge date, date of death; and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older;
(D) Telephone numbers;
(E) Fax numbers;
(F) Electronic mail addresses;
(G) Social security numbers;
(H) Medical record numbers;
(I) Health plan beneficiary numbers;
(J) Account numbers;
(K) Certificate/license numbers;
(L) Vehicle identifiers and serial numbers, including license plate numbers;
(M) Device identifiers and serial numbers;
(N) Web Universal Resource Locators (URLs);
(O) Internet Protocol (IP) address numbers;
(P) Biometric identifiers, including finger and voice prints;
(Q) Full face photographic images and any comparable images; and
(R) Any other unique identifying number, characteristic, or code; and ...

HIPAA’s Security Rule’s Standards Primer

This section helps you understand the thrust of the standards of the Security Rule. Examples of “standard” include “Security Management Process” and “Access Control”. Standards fall into three categories of safeguards: administrative, physical, and technical. Under each standard are implementation specifications – a high level “what to do” guide for each standard.

There are two types of implementation specifications: required and addressable. “Required” implementation specifications are required. “Addressable” implementation specifications allow organizations to use alternate implementations to achieve the security standard. Some implementation specifications might not be applicable to some organizations. In this case, the organization does not have to implement the measures, but it must document its decision to not implement them. Please review the finalized rule for details.

This section explains each standard using concepts in parts 1 and 2 of this book, so that they are more easily understood.

1. Administrative Safeguards
Security Management Process
This overarching standard requires that your organization must identify how availability, integrity, and confidentiality of PHI can be compromised and take security measures to reduce the likelihood of compromise. Discipline people if you have to.

Assigned Security Responsibility
The organization must clearly designate the person who is responsible for its security program. Assigning clear responsibility assures that the job gets done.

Workforce Security
Make sure the right internal people have access to PHI. Remove access when people should no longer have access to PHI. Access management should be ongoing.

Information Access Management
Make sure that you continue to provide the right access to internal/external applications and external users. Access management should be ongoing.

Security Awareness and Training
Encourage security awareness among your internal users with reminders and training. Training should include measures to protecting against evil software, detecting irregularities in last login data, and using strong passwords. Security can be enhanced through the participation of internal users.

Security Incident Procedures
Have a process and organization in place so that the organization can respond to security incidents. Keep records of the history.

Contingency Plan
Have ongoing processes to backup data. Have a reaction plan including recovery plans and interim operation plan in place for occasions when availability is compromised. Make sure the plan actually works. You want to avoid discovering that there’s a glitch in the recovery program when you actually have to recover data.

Adjust security measures to protect PHI as circumstances change. The security program should be ongoing.

Business Associate Contracts and Other Arrangement
Get documented assurances from business associates that they will safeguard shared PHI. Organizations should not ignore how shared PHI is being handled by business associates.

2. Physical Safeguards
Facility Access Controls
Only allow the right people with the right physical access during normal operations and during special operations. During special operations such as disaster recovery, people who are not allowed physical access during normal operation may need to enter the facility. Keep track of who goes in and out.

Workstation Use
Understand and define what role each workstation or type of workstation should be allowed to take with respect to PHI. If a workstation has a specific role, then you can monitor the workstation to verify that the workstation is not doing stuff it shouldn’t be doing.

Workstation Security
Protect workstations in the physical space so only the right people access PHI.

Device and Media Controls
Ensure that PHI on devices and media do not escape. Protect against the physical theft of data.

3. Technical Safeguards
Access Control
Only allow the right people to have accounts that access PHI. Do not share accounts. Accounts that are left with a user logged on should be automatically closed and the user logged off.

Audit Controls
Make sure that your system is operating in the manner expected.

Protect against unauthorized changes to data. Make sure that the PHI data being access is the right data.

Person or Entity Authentication
Make sure the right people and organizations are accessing PHI.

Transmission Security
Ensure integrity of PHI is preserved when transmitted. Encrypt transmissions of PHI when eavesdropping is enough of a risk.

The Security Rule does not prioritize the safeguards.

A possible approach to prioritizing the implementation of these safeguards is to identify where the highest risk of compromise is and implement security measures that effectively reduce the risk and are easy to implement.

If you have no physical protection of your sensitive assets, implement barriers to your equipment room. If it’s been a very long time since you’ve checked whether the right internal people have the right access rights to PHI, update your access control assignments. Worry about making this an ongoing process later. If there are no measures to ensure that only the right external users and applications are accessing PHI, then erect network-based and host-based barriers to block unauthorized outsiders.

It’s important to look at the actual standard itself to understand its details and history. This article serves as a primer. Reviewing parts 1 and 2 of this book will help you understand the context of the Security Rule’s implementation specifications and get more concrete ideas of the security measures you should implement.

Next Article:
Article 23: Other Compliance Standards: SOX and NERC

Go to: Table of Contents

Bookmark and Share

Thursday, July 2, 2009

21: PCI DSS - Payment Card Industry Data Security Standard

Payment Card Industry Data Security Standard [PCI DSS] was created to ultimately reduce the theft and fraudulent use of cardholder information by providing guidance to merchants on safeguarding the confidentiality of payment card information. The PCI Security Standards Council, the body that created the standard, was established by major credit card companies.

PCI DSS provides many specific technical measures as well as some abstract guidance. With an understanding of parts 1 and 2 of this book, we can fit the measures into the larger context of cybersecurity and “fill in the details” of some of the abstract guidance given in the standard.

Where To Get PCI DSS

The official PCI DSS website is here:

As of July 2009, a copy of the latest standard is available here:

A prioritized list of requirements is available here:

PCI DSS’s Sensitive Information

The scope of PCI DSS includes all systems and equipment that are potential paths to the compromise of the confidentiality of cardholder information. This includes systems that are not necessarily owned by your organization such as third party systems that your organization relies on.

PCI requires the following sensitive data to be protected:

  1. Primary Account Number
  2. Cardholder Name
  3. Service Code
  4. Expiration Date

No other card related data should be stored.

The standard requires measures that are one-time design measures, ongoing maintain/monitor measures, and reaction plan measures that involve technology, people, and processes. In addition, the standard describes methods to test that security measures are actually operating as envisioned. The requirements address security issues of external and internal users.

PCI DSS Requirements Primer

This section helps you understand the thrust of each PCI requirement. The title of each requirement has been rewritten to help you more easily understand the standard.

Requirement 1 – Design your network to be secure
Design your network to be secure. This includes designing the network topology and configuring your perimeter network equipment so that sensitive assets are not easily reached by external users.

Requirement 2 – Design your hosts to be secure
Requirement 1 focused on the network. Requirement 2 covers configuration of hosts. Follow the minimization rules to reduce the vulnerabilities of host.

Requirement 3 – Encrypt cardholder data
Store only the data you are allowed to store. Encrypt the data that you do store. Protect your decryption keys.

Requirement 4 – Encrypt cardholder data transmissions
Encrypt cardholder data when transmitting them on public networks.

Requirement 5 – Maintain defense against evil software
Protect against evil software.

Requirement 6 – Maintain defense by patching vulnerabilities
Patch vulnerabilities in operating systems, servers, and applications including your own application – especially if they are exposed to external users.

Use development best practices to develop custom applications so vulnerabilities are minimized and no rogue developer is embedding evil programs.

Don’t mix real cardholder data in the product environment and mock data for development and testing of your application. If you do, you’ll be revealing real cardholder data to your developers.

Requirement 7 – Give accounts to the minimal number of people
Don’t give data access to people who don’t need the data.

Requirement 8 – Manage and protect accounts
Don’t share accounts. Make account passwords hard to guess.

Requirement 9 – Protect your assets in the physical space
Protect your assets in the physical space.

Requirement 10 – Monitor for bad things happening
Use audit data to detect bad things happening. Keep an audit trail of activities and protect the audit trail data.

Requirement 11 – Maintain defenses
Test your defenses periodically. Maintain tools, such as IDS, that you are using to detect bad things.

Requirement 12 – Make defense an ongoing activity throughout your organization
Train your people. Make processes that make protecting the confidentiality of cardholder data a regular part of your organization’s work.

Tackling all 12 requirements at once is challenging. Prioritizing these requirements can help your organization follow a logical trajectory to eventually satisfying the requirements.

From a technical standpoint, it makes sense to design the groundwork of the system to be defensible before adding new monitoring systems on top. Comprehensive documentation should come later; documents, however, should not be completely ignored if writing them helps you get design work done. The design of the system drives how the system will be maintained and monitored. Once the underlying design is stable, investing in monitoring/auditing systems and other systems that run on top of your fundamental design makes more sense.

PCI DSS 1.2 suggests a series of milestones that the organization should achieve. Achieving the milestones involves satisfying a variety of specific “sub-requirements” spread across the 12 requirements.

PCI DSS suggests milestones in the following order:
  1. Minimize the amount of sensitive data that you have. Get rid of card data that you are not allowed to store in the first place. Destroy media holding sensitive data when the storing data on media serves no useful purpose.
  2. Design your network to be secure and encrypt transmissions of card data.
  3. Design your hosts and the applications to be secure.
  4. Maintain access control by giving accounts only to the right people and protect the accounts.
  5. Design your physical space to be secure.
  6. Design monitoring systems to watch over the system and make maintaining defense of card data an ongoing part of your organization.

It’s important to look at the actual standard itself to understand its details and its prioritization. This article serves as a primer to help you avoid getting bogged down in details of the standard.

Next Article:
Article 22: HIPAA - Health Insurance Portability and Accountability Act

Go to: Table of Contents

Bookmark and Share


Now that we covered the CyberSecurity Framework and examples of security measures, we are better equipped to understand compliance requirements.

Reading compliance standards for HIPAA or SOX without background knowledge of IT security can be difficult because you are trying to understand abstract guidance.

Part 1 and 2 of this book teaches you an approach to cybersecurity. Part 3 reviews a few selected compliance standards and explains them in a way that leverages cybersecurity concepts already presented.

Next Article:
Article 21: PCI DSS - Payment Card Industry Data Security Standard

Go to: Table of Contents

Bookmark and Share

20: Security Measures for Confidentiality

Focus of This Article

In addition to the security measures preventing unauthorized account acquisitions, another layer of security measures can be applied downstream in the logical space to safeguard confidentiality. Costs and benefits of these downstream security measures should be considered before their implementation. The more effectively upstream measures are implemented, the less valuable downstream measures may be.

These measures can also be considered when you are concerned about trusted users going “rogue” and inflicting harm against your organization.

This article follows the pattern established by previous articles about safeguarding availability and integrity. The additional layer of security measures involves monitoring the actual viewing activities of the user and monitoring/blocking the information from escape.

Data Access Points
There are multiple logical access points to data. Someone can access data through a client application. For instance, someone can use a sales management system to view customers’ purchase histories and their credit card numbers. The software client to the system’s application is an access point. However, if this data resides inside a database, then someone can directly access the data in the database without the software client.

It is important to use this idea when applying account management security measures discussed in an earlier article. The accounts of both the application and the underlying database should be maintained.

Security Measures
Security measures in addition to the account management measures described in an earlier article can be considered for preserving data confidentiality.

One security measure is to track which trusted user is viewing what information.

The thief must escape with sensitive data beyond the boundaries of your IT infrastructure to profit. Blocking the thief’s escape is another measure that can be taken to safeguard data confidentiality. The escape routes are numerous and some are extremely difficult to block.

Escape Routes of Sensitive Information:
  1. Memorize it.
  2. Write it down.
  3. Print it out.
  4. Send it via facsimile.
  5. Copy and paste it into a web mail service – if not text, then take screen captures and upload as attachment to web mail service.
  6. Send it out as attachment in email from company account.
  7. Send it out as body of message in email from company account.
  8. Transfer the file using FTP, scp, or similar file transfer client.
  9. Transfer using peer-to-peer file sharing clients or applications like Skype that support file transfer.
  10. Transfer data to portable media like a USB memory key or other portable storage device, and leave with device.
  11. Transfer data to writable DVD’s or CD’s and leave with media.

Security measures that safeguard confidentiality are:
  1. Monitor who is viewing sensitive information.
  2. Block escape routes.

Implementation Approach – Illustrative Examples
Let’s assume that we are an e-commerce company that stores customer credit card information. A web application calls the credit card numbers so it can place a charge on the customer’s credit card when he checks out his shopping cart. We are safeguarding the confidentiality of credit card numbers.

Monitoring Who Is Viewing Sensitive Information
Application logs or database logs are potential sources of information to monitor which users are viewing what. However, logs may not generate the information that you need to implement the security measures. If the logs do generate the information that you need, the logs will generate other information that you do not need. You may collect so much data that no analysis tool can easily process the records that you need.

If logs do not contain the necessary information, then you will have build or buy a product that allows you to monitor who is viewing which sensitive information.

Alert Example
Sensitive information such as credit card numbers should only be called by a known set of function calls of the web application. If an inappropriate function calls the database for sensitive data or someone is querying the database directly, something fishy is going on. An alert should be sent. The security team should investigate the root cause and take appropriate action depending on the results of the investigation.

Block Escape Routes
Blocking escape routes only when confidential data is on the verge of escaping is difficult to do because a thief can obfuscate the data that is escaping. For instance, a 16 digit number on an email can be detected as a credit card number and blocked from escaping the company; however, a smart thief can disguise the 16 digit number by adding letters in between the digits or simply transforming the 16 digit number into letters or words. Building intelligence into software so it can detect when sensitive data is leaving is challenging.

Design Example
Employees’ personal computers can be configured such that some escape routes are blocked. For instance, the personal computer’s USB can be disabled for data transfer to a USB memory key and other storage devices. Furthermore, it can be configured to disallow installation of applications such as FTP or other file transferring applications.

An agent can be installed on the personal computer to scan email for sensitive information. This agent can also monitor for sensitive information being pasted into web mail applications. When violations are detected, the action can be blocked and an alert can be sent to the IT security team.

It is important to note that these measures undermine the conveniences that employees are accustomed to having. A simple example is the transfer of a large file between employees. Transfer via email is not possible because the email system rejects big files. All other routes are blocked.

Going Beyond the Examples

There may be clever approaches to block escape routes for only people who have access to sensitive information. Not every person may need to be monitored.

Some development shops in India use the following procedure to ensure that their client’s software is protected from theft. Each employee entering the office is searched to ensure that he is not bringing in anything but himself. In the office, he works on a computer that is not connected to the Internet. At the end of the day, he is searched to ensure that he is not leaving with anything from the office.

Encrypt Confidential Information

Confidential information should be encrypted when transmitted on the network, especially public networks where anyone can be eavesdropping.

We covered additional measures that can be taken as lines of defense in addition to the initial safeguards of providing accounts and appropriate privileges to the right people to protect data confidentiality.

Next Article:
Part 3: Compliance

Go to: Table of Contents

Bookmark and Share