Showing posts with label PCI. Show all posts
Showing posts with label PCI. Show all posts

Monday, March 30, 2015

The Emerging Recognition of Governance

Thank you Verizon. Fantastic report. The authors did a wonderful job and my hat is off to you. Thank you Dark Reading. Thank you twit.

Governance really is THAT important.

Security used to look something like this… https://www.youtube.com/watch?v=D0n8N98mpes. Then organizations started to focus on compliance when Sarbanes-Oxley and in PCI became mandatory and prevalent. Security professionals realized that compliance in and of itself wasn't enough, and the focus shifted to addressing risk. Problem is that people still feel like they are playing Wack-a-Mole. The governance problem started becoming… A problem. It grew geometrically with the number of different new systems, vendors, applications, interconnections, interfaces, and dependencies.

During the lifecycle of the system there are different security and risk challenges that must be solved, such as those described in context of a PCVMR Cycle, which recognizes the importance of maintaining the system over time.

Let's look at operational hygiene, or governance, in the lands of a state security model. You start at the 0 when the system has been validated/authorized for operations. Ideally at that moment in time the system is fully secure without any flaws. You've tested the system against known attacks and established that the system is properly secured to your baselines. Over time, however, the adjusted state for where you should be is a slight trajectory upwards with some growth to recognize changes in security posture/configurations, architecture, design, firmware, patches, control inheritance, additional solutions, etc.

Compare the state of where you should be vs. the day 0 configuration and what you find is that over time you have a greater gap. Let's call this current state vs. secure state gap "drift". The drift/gap gets larger over time, and leaves you susceptible to compromise. Now go back and look at the wonderful statistics the Verizon team put together and read the column in red.

Does compliance = security? Depends. Depends on whether you recognize a properly implemented risk management framework as necessary to meeting the compliance requirements. Depends on whether you recognize compliance requirements must be managed over time. Depends on whether you have the right people who understand, processes that enforce, and tools that execute and track governance of your systems.

Thursday, November 17, 2011

VMware vCloud Director Segmentation: PCI and HIPAA Firewall Controls

This came up last week and I thought I would post here to keep the information easily accessible.

Yes. You can use vCD to segment environments that are required to comply with HIPAA and/or PCI.

The firewall functions in vCD in no way preclude you from using vCD to host production Primary Account Number (PAN) or electronic Private Healthcare Information (ePHI) as long as you comply with all of the other controls required to host the information. Here are the details from the requirements along with specific comments.

PCI has an entire section devoted to firewall controls (Requirement 1: Install and maintain a firewall configuration to protect cardholder data), of which the most restrictive requirements are [1] the ability to implement ACLs, and [2] SPI/Dynamic Packet Filtering.

Requirement 1.3.6 
Verify that the firewall performs stateful inspection (dynamic packet filtering). (Only established connections should be allowed in, and only if they are associated with a previously established session.) 

HIPAA has specific segmentation requirements for health care clearinghouse functions found here. Although they are specifically called out as Administrative Controls, the definition for this bill is defined as:

Sec. 164.304  Definitions 
Administrative safeguards are administrative actions, and policies  and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect electronic protected  health information and to manage the conduct of the covered entity's workforce in relation to the protection of that information. 

Note the lack of any detailed requirements – intentionally – to allow a broad range of solutions to fit the requirement.

164.308(a)(4)(ii)(A)
(ii) Implementation specifications:
    (A) Isolating health care clearinghouse functions (Required). If ahealth care clearinghouse is part of a larger organization, the clearinghouse must implement policies and procedures that protect the electronic protected health information of the clearinghouse from unauthorized access by the larger organization. Sec. 164.304 Definitions