If you are following my blog, you’ve probably noticed that I’ve been focusing on security-specific AWS services in my previous several posts. It’s time to bring them all together into one consolidated view. I’m talking, of course, about the AWS Security Hub.
You can group, filter and prioritise findings from these services in many different ways. And, of course, you can visualise and make dashboards out of them.
Apart from consolidating findings from other services, it also assesses your overall AWS configuration against PCI DSS and/or the CIS Amazon Web Services Foundations Benchmark, which covers identity and access management, logging, monitoring and networking, giving you the overall score (example below) and actionable steps to improve your security posture.
Similar to the many other AWS services, Security Hub is regional, so it will need to be configured in every active region your organisation operates. I also recommend setting up your security operations account as a Security Hub master account and then inviting all other accounts in your organisation as members for centralised management (as described in this guidance or using a script).
If you are not a big fan of the Security Hub’s interface or don’t want to constantly switch between regions, the service sends all findings to CloudWatch Events by default, so you can forward them on to other AWS resources or external systems (e.g. chat or ticketing systems) for further analysis and remediation. Better still, you can configure automated response using Lambda, similar to what we did with Inspector findings discussed previously.
The PCI Security Standards Council is an open global forum, launched in 2006, that is responsible for the development, management, education, and awareness of the PCI Security Standards, including the Data Security Standard (PCI DSS), Payment Application Data Security Standard (PA-DSS), and PIN Transaction Security (PTS) requirements.
The PCI Security Standards Council also develops and manages a number of programs to build awareness and to train, test, and qualify organizations and individuals to assess and validate adherence to PCI Security Standards.
They put together a short video explaining the basic principles.
Conducting an awareness training or explaining complex information security concepts can be simplified and made fun through gamification. It is possible to learn more about information security simply by playing card games. Please see below for the three games you can download for free, print and start playing today.
1. Playing with application vulnerabilities
OWASP Cornucopia is a mechanism in the form of a card game to assist software development teams identify security requirements in Agile, conventional and formal development processes. It is language, platform and technology agnostic.
2. Playing with threat modelling
Elevation of Privilege (EoP) is the easy way to get started threat modelling, which is a core component of the design phase in the Microsoft Security Development Lifecycle (SDL).
The EoP card game helps clarify the details of threat modelling and examines possible threats to software and computer systems.
The EoP game focuses on the following threats:
- Information Disclosure
- Denial of Service
- Elevation of Privilege
An academic-style paper explains the rules motivation and lessons learned in creating the game
The VOME project created a card game to support the discussion and teaching of issues of online privacy and consent. Players make decisions about what information characters might reveal to others and what they keep to themselves.
According to the authors, the main idea behind the game is to use the rules to model the way that information flows around the online environment. In real life, these flows are complex and often hidden. In the game it is possible simplify the relationships and decisions, and provide immediate feedback on the effects of those decisions
According to the statistical survey  security is one of the main concerns for enterprises when making the decision to outsource their applications and infrastructure to the cloud computing environment
The inability to clearly identify where the sensitive data is stored and how it is processed is a major concern of many companies.
The problem becomes more serious when the enterprise processes cards payments and has to comply with regulatory requirements, such as PCI DSS. A need for compliance of the infrastructure with regulatory requirements plays an important role when having to decide whether to move applications or infrastructure to the cloud.
This chapter will identify specific requirements for PCI DSS compliance in a cloud computing environment and will look at research done in the field of continuous auditing.
1. PCI DSS compliance and virtualization
Virtualization, which serves as a foundation for cloud computing, introduces new unique types of risks that must be taken into consideration when deciding on adopting cloud computing in cardholder data environment. 
To address these concerns and to achieve PCI DSS compliance in such environment, PCI Security Standards Council issued “PCI DSS Virtualization Guidelines,” providing an example of how scope and responsibility may differ by type of cloud service (Figure 1) 
Figure 1 – Area of responsibility by type of cloud service 
In their supplement guidance PCI Security Standards Council also focuses on following risks :
– Vulnerabilities in the Physical Environment Apply in a Virtual Environment
– Hypervisor Creates New Attack Surface
– Increased Complexity of Virtualized Systems and Networks
– More Than One Function per Physical System
– Mixing Virtual machines of Different Trust Levels
– Lack of Separation of Duties
– Dormant Virtual Machines
– Virtual machines Images and Snapshots
– Immaturity of Monitoring Solutions
– Information Leakage between Virtual Network Segments
– Information Leakage between Virtual Components
For each risk they provide a set of recommendations, specifically covering compliance aspects of the cloud computing environment.
2. Continuous compliance monitoring in cloud computing environment
Ensuring the compliance of outsourced business processes to regulatory requirements is one of the key problems in the deployment of cloud computing environment , 
Some research has been done in the field of developing models to automate the process of continuous auditing in order to ensure adherence to regulatory requirements.
Building on Speeter’s research , Chieu, Viswanathan, and Gupta in their work , push the concept further and not only provide solutions on gathering information on network and server configuration, but also provide a tool to automate this process and use collected evidence for assurance purposes.
The researchers acknowledge all possible benefits of cloud computing, but mention that “the steps of validating the configuration and security of the target workload for compliance and assuring its quality may be complex and very time consuming.” Emphasizing the difficulties of the validation process when performed manually, the authors present the design of an automation system (Figure 2) to carry out the validation of configuration on target cloud services for compliance .
Figure 2 – Architecture of the automation system for service activation 
The authors describe in detail how to use the presented system to collect and verify all collected evidences and ensure adherence with the regulatory requirements in the cloud computing environment. This development makes a large practical contribution, and supports various operating systems and middleware stacks. It also was deployed in shared private enterprise cloud (IBM SmartCloud Enterprise Plus . However, authors acknowledge that the developed system “lacks the flexibility to support the diverse private cloud environments in which different back-end tools may have to be integrated.”  Allowing such flexibility may result in wider adoption and use for practical purposes, such as automation of PCI DSS compliance checks.
Acknowledging the contribution of Breaux and Antón’s research  Accorsi and Sato claim that there is still no sufficient research results to support creation of a uniform way of expressing the compliance requirements . Moreover, in their paper, the researchers emphasize the absence of tools for automating certification procedures, and that the “multitude of regulations and contractual rules increases the complexity of checking compliance” .
The authors analyze some regulatory requirements and develop nine common categories. They then focus on workflows and create Petri net , , ,  representation of these categories. They use the developed model to check the compliance of a given business process in relation to a given requirements. In case of non-compliance, the developed model gathers necessary evidence and points out to the problem.
Unlike Sadiq, Governatori, Namiri , who focus only on a single legislation, Accorsi and Sato present their categorization using several different legislations, which may be beneficial for cloud service providers who need to comply simultaneously with many different regulations. However, in their research, the authors analyze mainly business process design issues and only several legislations, ignoring, for example, PCI DSS and, more importantly, many requirements which may be specific for this legislation.
Hizver and Chiueh in their paper  tackle another side of automated compliance monitoring – discovering credit card flow, which is a pre-requisite to the implementation of PCI DSS.
Their research has valuable practical application, because in order to comply with PCI DSS requirements, merchants must understand how credit card data flows in their information technology infrastructure and must document it. This may result in problems with out-of-date and difficult to maintain documentation of this flow when infrastructure changes.
To avoid manual effort, the authors develop a tool that can discover payment card data flow from distributed systems in an automated manner. The foundation of the tool is virtual machine introspection technology .
Researchers present and thoroughly analyze the developed tool and show evidence that it can fulfill its purpose, despite the fact that communications between distributed systems are encrypted.
Existing issues with compliance monitoring prevent companies from outsourcing their application and infrastructure to a third party cloud computing environment  and slow down the process of realization of the cloud computing potential .
Although some positive results are achieved in the field of identifying problems with cloud computing and compliance, more research should be done in the field of automation of continuous monitoring for PCI DSS requirements in a cloud computing environment. Models should be developed and tested to allow companies to ensure their adherence with requirements not only of application, but also of external environment, especially if outsourced to third parties.
 IDC Survey (2009) http://blogs.idc.com/ie/?p=730
 PCI DSS Virtualization Guidelines (2011) https://www.pcisecuritystandards.org/documents/Virtualization_InfoSupp_v2.pdf
 ENISA (2009)” Cloud computing—benefits, risks and recommendations for information security”. European Network Information and Security Agency
 Cloud Security Alliance (2013)” Top threats to cloud computing”
 Speeter, Framba, Duncan, Talla, Bullis, (2006) “Configuration management system and method of discovering configuration data”, US Patent Pub. No. 20060179116
 Chieu, Viswanathan, Gupta (2012) “Automation System for Validation of Configuration and Security Compliance in Managed Cloud Services”
 IBM SmartCloud, http://www.ibm.com/cloud-computing/us/en/
 Breaux, Antón (2008) “Analyzing regulatory rules for privacy and security requirements”. IEEE Trans Software Eng 34(1) p.5–20
 Accorsi, Sato (2011) “Automated Certification for Compliant Cloud-based Business Processes” DOI 10.1007/s12599-011-0155-7
 Murata (1989) “Petri nets: properties, analysis and applications”. Proc IEEE 77(4 :p.541–580
 van der Aalst (1998) “The application of Petri nets to workflow management”. Journal of Circuits, Systems, and Computers 8(1): p.21–66
 Katt, Zhang Hafner (2009)” Towards a usage control policy specification with Petri nets”. Springer LNCS 5871: p.905–912
 Huang, Kirchner (2009)” Component- based security policy design with colored Petri nets”. Springer LNCS 5700: p.21–42
 Sadiq, Governatori, Namiri (2007) “Modeling control objectives for business process compliance. Business process management”. Springer LNCS 4714: p.149–164
 Hizver, Chiueh (2011) “Automated Discovery of Credit Card Data Flow for PCI DSS Compliance”, 30th IEEE International Symposium on Reliable Distributed Systems
 Garfinkel, Rosenblum (2003) “A virtual machine introspection based architecture for intrusion detection,” Proc. Network and Distributed Systems Security Symposium,, p. 191-206.
 Chow, Golle , Jakobsson Staddon, Masuoka, Molina (2009) “Controlling data in the cloud: outsourcing computation without outsourcing control”. In: Proc ACM workshop on cloud computing security. ACM, New York, pp 85–90
 Etro (2009) “The economic impact of cloud computing on business creation, employment and output in Europe”. Review of Business and Economics 54(2):p.179–218
The main purpose of this article series is to survey the research that have been done in areas of PCI DSS compliance and recent developments of cloud computing. It gives an overview of basics of cloud computing, PCI DSS and specific compliance issues when dealing with outsourcing applications and infrastructure to third parties.
Nowadays many companies changed the way they doing business with the development of cloud computing. An ability to outsource application or entire infrastructure to the third parties allows businesses to take advantage of rapid and highly scalable deployment of services with little or no information technology expertise. Unfortunately, many enterprises are slow to adopt cloud computing because of information security compliance issues. Companies are skeptical about moving their sensitive information outside their own control perimeter, and see their main obstacle as an inability to check whether outsourced infrastructure and applications are in conflict with existing rules and regulations, such as PCI DSS.
The Payment Card Industry Data Security Standard (PCI DSS)
Payment Card Industry Data Security Standard (PCI DSS) is a standard that organizations must follow if their business involves processing, storing, and transmitting cardholder data. The main purpose of this standard is to provide requirements to ensure security of payment card data
1. Overview and history
PCI DSS was developed by PCI Security Standards Council, an open global forum formed in 2006 by American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. .
Historically, the companies in this forum developed their own programs, but because they shared similar goals they decided to align their requirements and created PCI DSS.
The birth of PCI DSS created many discussions in the industry.
For example, PCI Council General Manager Bob Russo thinks that PCI DSS gives stakeholders “the opportunity and flexibility to work with Qualified Security Assessors (QSA) to determine appropriate security controls within their environment that meet the intent of the PCI standards.” 
Furthermore, Bruce Schneier says that, “Regulation – SOX, HIPAA, GLBA, the credit-card industry’s PCI, the various disclosure laws, the European Data Protection Act, whatever – has been the best stick the industry has found to beat companies over the head with. And it works. Regulation forces companies to take security more seriously, and sells more products and services.” 
2. PCI DSS requirements compliance
PCI DSS consists of on six high-level objectives and twelve requirements (Table 1) 
|Build and maintain a secure network||1. Install and maintain a firewall configuration to protect cardholder data|
|2. Do not use vendor supplied defaults for system passwords and other security parameters|
|Protect card holder data||3. Protect stored cardholder data|
|4. Encrypt transmission of cardholder data across open, public networks|
|Maintain a vulnerability management program||5. Use and regularly update antivirus software or programs|
|6. Develop and maintain secure systems and applications|
|Implement strong access control measures||7. Restrict access to cardholder data by business need to know|
|8. Assign a unique ID to each person with computer access|
|9. Restrict physical access to cardholder data|
|Regularly monitor and test networks||10. Track and monitor all access to network resources and cardholder data|
|11. Regularly test security systems and processes|
|Maintain and information security policy||12. Maintain a policy that addresses information security for all personnel.|
Table 1 – PCI DSS Requirements and Security Assessment Procedures 
Compliance with PCI DSS requirements is enforced through contract agreements and may include fines and higher processing fees. To ensure compliance of services providers and merchants with PCI DSS requirements, special assessments are carried out. Such assessments usually utilize a sampling methodology to demonstrate compliance in target systems.
However, assessment procedure depends on the level of the merchant (it may require the completion of a Self-Assessment Questionnaire or on-site assessment) (Table 2) 
|Level 1||Any merchant that has suffered a hack or an attack that resulted in an account data compromise
Any merchant having more than six million total combined MasterCard and Maestro transactions annually
Any merchant that MasterCard, in its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the system
|Annual Onsite Assessment
Quarterly Network Scan
|Level 2||Any merchant with more than one million but less than or equal to six million total combined MasterCard and Maestro transactions annually||Annual Self-Assessment
Onsite Assessment at Merchant Discretion
Quarterly Network Scan
|Level 3||Any merchant with more than 20,000 combined MasterCard and Maestro e-commerce transactions annually but less than or equal to one million total combined MasterCard and Maestro e-commerce transactions annually||Annual Self-Assessment
Quarterly Network Scan
|Level 4||All other merchants||Annual Self-Assessment
Quarterly Network Scan
Table 2 – Merchant Level and Validation Requirements (MasterCard version) 
PCI DSS requirements assessment procedure depends on merchant’s annual number of transactions and past breach history.
3. Implementing the PCI DSS
Companies face many challenges and difficulties when implementing PCI DSS requirements. According to Michael Jones, CIO of Michaels’ Stores, PCI DSS requirements “are very expensive to implement, confusing to comply with, and ultimately subjective, both in their interpretation and in their enforcement. It is often stated that there are only twelve ‘Requirements’ for PCI compliance. In fact there are over 220 sub-requirements; some of which can place an incredible burden on a retailer and many of which are subject to interpretation.” 
Rees identifies the following challenges of PCI DSS compliance :
– Understanding scope
– Understanding of card data flow
– Third party management
Bonner, O’ Raw and Curran in their paper  present a good analysis of application adherence with PCI DSS requirements. Researchers address such issues as maintaining legacy systems and their difficulties to implement PCI DSS requirements properly. They discuss several existing solutions such as using web services to “wrap” older legacy systems . However, in their opinion, neither of these approaches directly addresses the problem of PCI DSS compliance.
The authors developed a prototype (Figure 1) and showed how to implement controls to achieve PCI DSS compliance in the application.
Figure 1 -. Experimental System Overview 
The researchers thoroughly describe their prototype, present some experiments, and tackle the problems of masking payment card data and cryptographic key management while storing such data.
However, in their research they focus solely on adherence with requirements of developed application, completely ignoring environment in which this piece of software operates.
Despite the fact that this paper contributes to the field of secure software development, and emphasizes some application PCI DSS compliance issues, one should remember that environment plays an important role in achieving compliance for business overall
 PCI Security Standards Council https://www.pcisecuritystandards.org/
 Russo (2009). “Letter to NRF”. PCI Council. https://www.pcisecuritystandards.org/pdfs/statement090615_letter_to_nrf.pdf
 Schneier (2008) “Bruce Schneier reflects on a decade of security trends”. http://www.schneier.com/news-049.html
 PCI DSS Requirements and Security Assessment Procedures, Version 2.0 p. 5
 Merchant Level and Validation Requirements (MasterCard version) http://www.mastercard.com/us/company/en/whatwedo/determine_merchant.html
 Jones (2009). “Testimony of Michael Jones before the emerging threats cybersecurity and science and technology subcommittee “. Congress of the United States.
 Rees (2010) “Computer Fraud & Security” Volume 2010, Issue 12, p. 14–116
 Bonner, O’ Raw, Curran (2011) “Implementing the Payment Card Industry (PCI) Data Security Standard (DSS)”.
 Steed (1996) “Encapsulating Legacy Software for Use in Client/Server Systems”. Proceedings of the Third Working Conference on Reverse Engineering. Monterey, CA: p.104-119