PCI SSC [Payment Card Industry Security Standard Council]Data Security Standards Overview

The PCI Security Standards Council offers robust and comprehensive standards and supporting materials to enhance payment card data security. These materials include a framework of specifications, tools, measurements and support resources to help organizations ensure the safe handling of cardholder information at every step. The keystone is the PCI Data Security Standard (PCI DSS), which provides an actionable framework for developing a robust payment card data security process — including prevention, detection and appropriate reaction to security incidents.

Tools to assist organizations validate their PCI DSS compliance include Self Assessment Questionnaires. The chart linked here shows some of the tools available to help organizations become PCI DSS-compliant.

For device vendors and manufacturers, the Council provides the PIN Transaction Security (PTS) requirements, which contains a single set of requirements for all personal identification number (PIN) terminals, including POS devices, encrypting PIN pads and unattended payment terminals. A list of approved PIN transaction devices can be accessed here.

To help software vendors and others develop secure payment applications, the Council maintains the Payment Application Data Security Standard (PA-DSS) and a list of Validated Payment Applications.

The Council also provides training to professional firms and individuals so that they can assist organizations with their compliance efforts. The Council maintains public resources such as lists of Qualified Security Assessors (QSAs), Payment Application Qualified Security Assessors (PA-QSAs), and Approved Scanning Vendors (ASVs). Large firms seeking to educate their employees can take advantage of the Internal Security Assessor (ISA) education program.

General audit terms defined in ISO 27001

  • Audit – the process by which a subject area is independently reviewed and reported on by one or more competent auditors on behalf of stakeholders
  • Audit checklist – a structured questionnaire or workplan to guide the auditors in testing the area being audited
  • Audit evidence – information gathered from the area being audited such as written documentation, computer printouts, interviews and observation
  • Audit finding – the auditor’s summary/description and analysis of an inadequately mitigated risk to the organization
  • Audit observation – an optional or advisory audit recommendation which carries less weight than an audit recommendation
  • Audit plan or programme – a project plan for an audit laying out the main audit activities and heir timing
  • Audit recommendation – a corrective action that is proposed to address one or more identified audit findings, that must be addressed prior to certification or recertification of the ISMS
  • Audit report – a formal report to management documenting the key findings and conclusions of the audit
  • Audit risk – the potential for an audit to fail to meet its objectives, for example by using unreliable, incomplete or inaccurate information
  • Audit schedule – a diary of planned audits
  • Audit subject – the in-scope organization/s, or parts of an organization, which are being audited
  • Audit test – a check conducted by the auditors to verify whether a control is effective, efficient and adequate to mitigate one or more risks to the organization
  • Audit work papers – documents written by the auditors recording their examination, findings and analysis of the ISMS, including completed audit checklists
  • Compliance audit – a type of audit specifically designed to assess the extent to which the audit subject conforms to stated requirements
  • ISMS audit – an audit centred on the organization’s Information Security Management System (ISMS)
  • Risk-based audit – an audit planned on the basis of an assessment of risks

Are you for ISO/IEC 27001:2013? Self Assessment

1. The organization and its context…
-Have the internal and external issues that are relevant to the ISMS, and that impact on the achievement of its expected outcome, been determined?

2. Needs and expectations of interested parties
-Has the organization determined the interested parties that are relevant to the ISMS?
-Have the requirements of these interested parties been determined, including legal, regulatory and contractual requirements?

3. Scope of the ISMS
-Have the boundaries and applicability of the ISMS been determined to establish its scope, taking into consideration the external and internal issues, the requirements of interested parties and the interfaces and dependencies with other organizations?
-Is the scope of the ISMS documented?

4. Leadership and management commitment
Is the organization’s leadership commitment to the ISMS demonstrated by:
• Establishing the information security policy and objectives, in consideration of the strategic direction of the organization, and in promotion of continual improvement?
• Ensuring the integration of the ISMS requirements into its business processes?
• Ensuring resources are available for the ISMS, and directing and supporting individuals, including management, who contribute to its effectiveness?
• Communicating the importance of effective information security and conformance to ISMS requirements?

5. Information security policy
-Is there an established information security policy that is appropriate, gives a framework for setting objectives, and demonstrates commitment to meeting requirements and for continual improvement?
-Is the policy documented and communicated to employees and relevant interested parties?
6. Roles and responsibilities
-Are the roles within the ISMS clearly defined and communicated?
-Are the responsibilities and authorities for conformance and reporting on ISMS performance assigned?

7. Risks and opportunities of ISMS implementation
-Have the internal and external issues, and the requirements of interested parties been considered to determine the risks and opportunities that need to be addressed to ensure that the ISMS achieves its outcome, that undesired effects are prevented or reduced, and that continual improvement is achieved?
-Have actions to address risks and opportunities been planned, and integrated into the ISMS processes, and are they evaluated for effectiveness?

8. Information security risk assessment
-Has an information security risk assessment process that establishes the criteria for performing information security risk assessments, including risk acceptance criteria been defined?
-Is the information security risk assessment process repeatable and does it produce consistent, valid and comparable results?
-Does the information security risk assessment process identify risks associated with loss of confidentiality, integrity and availability for information within the scope of the ISMS, and are risk owners identified?
-Are information security risks analysed to assess the realistic likelihood and potential consequences that would result, if they were to occur, and have the levels of risk been determined?
-Are information security risks compared to the established risk criteria and prioritised?
-Is documented information about the information security risk assessment process available?

9. Information security risk treatment
-Is there an information security risk treatment process to select appropriate risk treatment options for the results of the information security risk assessment, and are controls determined to implement the risk treatment option chosen?
-Have the controls determined, been compared with ISO/IEC 27001:2013 Annex A to verify that no necessary controls have been missed?
-Has a Statement of Applicability been produced to justify Annex A exclusions, and inclusions together with the control implementation status?
-Has an information security risk treatment plan been formulated and approved by risk owners, and have residual information security risks been authorised by risk owners?
-Is documented information about the information security risk treatment process available?

10. Information security objectives and planning to achieve them
-Have measurable ISMS objectives and targets been established, documented and communicated throughout the organization?
-In setting its objectives, has the organization determined what needs to be done, when and by whom?

11. ISMS resources and competence
-Is the ISMS adequately resourced?
-Is there a process defined and documented for determining competence for ISMS roles?
-Are those undertaking ISMS roles competent, and is this competence documented appropriately?

12. Awareness and communication
-Is everyone within the organization’s control aware of the importance of the information security policy, their contribution to the effectiveness of the ISMS and the implications of not conforming?
-Has the organization determined the need for internal and external communications relevant to the ISMS, including what to communicate, when, with whom, and who by, and the processes by which this is achieved?

13. Documented information
-Has the organization determined the documented information necessary for the effectiveness of the ISMS?
-Is the documented information in the appropriate format, and has it been identified, reviewed and approved for suitability?
-Is the documented information controlled such that it is available and adequately protected, distributed, stored, retained and under change control, including documents of external origin required by the organization for the ISMS?

14. Operational planning and control
-Has a programme to ensure the ISMS achieves its outcomes, requirements and objectives been developed and implemented?
-Is documented evidence retained to demonstrate that processes have been carried out as planned?
-Are changes planned and controlled, and unintended changes reviewed to mitigate any adverse results?
-Have outsourced processes been determined and are they controlled?
-Are information security risk assessments performed at planned intervals or when significant changes occur, and is documented information retained?
-Has the information security risk treatment plan been implemented and documented information retained?

15. Monitoring, measurement and evaluation
-Is the information security performance and effectiveness of the ISMS evaluated?
-Has it been determined what needs to be monitored and measured, when, by whom, the methods to be used, and when the results will be evaluated?
-Is documented information retained as evidence of the results of monitoring and measurement?

16. Internal audit
-Are internal audits conducted periodically to check that the ISMS is effective and conforms to both ISO/IEC 27001:2013 and the organization’s requirements?
-Are the audits conducted by an appropriate method and in line with an audit programme based on the results of risk assessments and previous audits?
-Are results of audits reported to management, and is documented information about the audit programme and audit results retained?
-Where non conformities are identified, are they subject to corrective action (see section 18)?

17. Management review
-Do top management undertake a periodic review of the ISMS?
-Does the output from the ISMS management review identify changes and improvements?
-Are the results of the management review documented, acted upon and communicated to interested parties as appropriate?

18. Corrective action and continual improvement
-Have actions to control, correct and deal with the consequences of non-conformities been identified?
-Has the need for action been evaluated to eliminate the root cause of non-conformities to prevent reoccurrence?
-Have any actions identified been implemented and reviewed for effectiveness and given rise to improvements to the ISMS?
-Is documented information retained as evidence of the nature of non-conformities, actions taken and the results?

19. Security controls – as applicable, based on the results of your information security risk assessment
-Are information security policies that provide management direction defined and regularly reviewed?
-Has a management framework been established to control the implementation and operation of security within the organization, including assignment of responsibilities and segregation of conflicting duties?
-Are appropriate contacts with authorities and special interest groups maintained?
-Is information security addressed in Projects?
-Is there a mobile device policy and teleworking policy in place?
-Are human resources subject to screening, and do they have terms and conditions of employment defining their information security responsibilities?
-Are employees required to adhere to the information security policies and procedures, provided with awareness, education and training, and is there a disciplinary process?
-Are the information security responsibilities and duties communicated and enforced for employees who terminate or change employment?
-Is there an inventory of assets associated with information and information processing, have owners been assigned, and are rules for acceptable use of assets and return of assets defined?
-Is information classified and appropriately labelled, and have procedures for handling assets in accordance of their classification been defined?
-Are there procedures for the removal, disposal and transit of media containing information?
-Has an access control policy been defined and reviewed, and is user access to the network controlled in line with the policy?
-Is there a formal user registration process assigning and revoking access and access rights to systems and services, and are access rights regularly reviewed, and removed upon termination of employment?
-Are privileged access rights restricted and controlled, and is secret authentication information controlled, and users made aware of the practices for use?
-Is access to information restricted in line with the access control policy, and is access controlled via a secure log-on procedure?
-Are password management systems interactive and do they enforce a quality password?
-Is the use of utility programs and access to program source code restricted?
-Is there a policy for the use of cryptography and key management?
-Are there policies and controls to prevent unauthorised physical access and damage to information and information processing facilities?
-Are there policies and controls in place to prevent loss, damage, theft or compromise of assets and interruptions to operations?
-Are operating procedures documented and are changes to the organization, business processes and information systems controlled?
-Are resources monitored and projections made of future capacity requirements?

-Is there separation of development, testing and operational environments?
-Is there protection against malware?
-Are information, software and systems subject to back up and regular testing?
-Are there controls in place to log events and generate evidence?
-Is the implementation of software on operational systems controlled, and are there rules governing the installation of software by users?
-Is information about technical vulnerabilities obtained and appropriate measures taken to address risks?
-Are networks managed, segregated when necessary, and controlled to protect information systems, and are network services subject to service agreements?
-Are there policies and agreements to maintain the security of information transferred within or outside of the organization?
-Are information security requirements for information systems defined and is information passing over public networks and application service transactions protected?
-Are systems and rules for the development of software established and changes to systems within the development lifecycle formally controlled?
-Are business critical applications reviewed and tested after changes to operating system platforms and are there restrictions to changes to software packages?
-Have secure engineering principles been established and are they maintained and implemented, including secure development environments, security testing, the use of test data and system acceptance testing?
-Is outsourced software development supervised and monitored?

-Are there policies and agreements in place to protect information assets that are accessible to suppliers, and is the agreed level of information security and service delivery monitored and managed, including changes to provision of services?
-Is there a consistent approach to the management of security incidents and weaknesses, including assignment of responsibilities, reporting, assessment, response, analysis and collection of evidence?

-Is information security continuity embedded within the business continuity management system, including determination of requirements in adverse situations, procedures and controls, and verification of effectiveness?
-Are information processing facilities implemented with redundancy to meet availability requirements?
-Have all legislative, statutory, regulatory and contractual requirements and the approach to meeting these requirements been defined for each information system and the organization, including but not limited to procedures for intellectual property rights, protection of records, privacy and protection of personal information and regulation of cryptographic controls?
-Is there an independent review of information security?
-Do managers regularly review the compliance of information processing and procedures within their areas of responsibility?
-Are information systems regularly reviewed for technical compliance with policies and standards?

The role of Enterprise Architecture

In the development of a house, building or any object we can always identify the following main steps:
• A discovery process to identify the needs and requirements in the context of a certain situation;
• A design process which leads to a design of the object in the form of drawings and/or models;
• A transformation process to plan the realisation of the object in its environment;
• A construction process that regards the realisation of the actual object based on the design and realisation plan.

The principles, guidelines and rules identified in the discovery phase are used in both the design, transformation and construction process. As such, the architecture impacts all processes.

The architecture constraints the freedom of the designer and constructor of the object and guides them towards a structure that complies with the business vision and concepts of the architecture. The architecture serves as a prescription for the
design, transformation and construction of the object. As a result the object will be recognised as being ‘designed and constructed under architecture’. The object will inherit the added value of the architecture and will support the (cultural) values, goals and objectives of the organisation. The described role of architecture originates from the building industry. In prescribing the structure, function and style of a building the architecture defines principles, guidelines and rules for:

• The type of components of which the building may be composed; • How these components must fit together; • What assemblies of the components are allowed;

• What functions (usage, living, and working) do the components and component assemblies support;

• And how the style represents the values of the owner. The prescription concerns the overall architecture as well as the design models and the actual construction of the building. IFEAD uses the same approach by defining the architectural steps for architecting business / organisations and IT systems. In prescribing the structure of an organisation and its related business or an IT system the architecture defines principles, guidelines and rules for:

• The type of components of which the business or system may be composed;

• How these components must fit together;

• How the components communicate and co-operate;

• What assemblies of the components are allowed;

• What functions (communication, control, security, and information) the components and component assemblies support;

• And how the style expresses the (cultural) values of the stakeholders of that organisation.

Developing an Enterprise Level Architectural Description

Paramount to the enterprise architecture is the identification of the sponsor, his/her mission, vision and strategy and the governance framework to define all roles, responsibilities and relationships involved in the anticipated transition.
As the purpose of architecture is: “INSIGHT, TO DECIDE, FOR ALL STAKEHOLDERS”, enterprise architects work very closely with the enterprise sponsor and key stakeholders, internal and external to the enterprise. The architect understands the enterprise mission, vision and strategy and the sponsor’s ideas about the approach. The architect articulates the existing enterprise infrastructure value-chain: market, business, systems and technology. Architects present and discuss the technology, systems, business and market options to fulfill the enterprise mission. Insight is improved by using the ‘solution architecture’ which is, relative to the decisions ahead, a specific blend of technology, systems, business and market options. Together with the sponsor and the main stakeholders, they make informed choices about the options. For large transitions, architectural decisions are supported by proofs-of-concept and/or business pilots.
Enterprise architects use various methods and tools to capture the structure and dynamics of an enterprise. In doing so, they produce taxonomies, diagrams, documents and models, together called artifacts. These artifacts describe the
logical organization of business functions, business capabilities, business processes, people, information resources, business systems, software applications, computing capabilities, information exchange and communications
infrastructure within the enterprise. A collection of these artifacts, sufficiently complete to describe the enterprise in useful ways, is considered by EA practitioners an ‘enterprise’ level architectural description, or enterprise architecture, for short. The UK National Computing Centre EA best practice guidance states Normally an EA takes the form of a comprehensive set of cohesive models that describe the structure and functions of an enterprise. and continues
The individual models in an EA are arranged in a logical manner that provides an ever-increasing level of detail about the enterprise: its objectives and goals; its processes and organization; its systems and data; the technology used and any other relevant spheres of interest. This is the definition of enterprise architecture implicit in several EA frameworks including the popular TOGAF architectural framework. An enterprise architecture framework bundles tools, techniques, artifact descriptions, process models, reference models and guidance used by architects in the production of enterprise-specific architectural description. Several enterprise architecture frameworks break down the practice of enterprise architecture into a number of practice areas or domains.

Why Produce an Enterprise Architecture Model ?

It is tempting to say that if the head of an organization doesn’t see the need for an EA model, then it is probably a simple enough organization not to need one. However, the truth is that most enterprises started out small and simple, where one person could genuinely understand the whole thing, but grew to the point where no single person could describe the whole. The same can be said of the corresponding IT systems that support the enterprise. The problem is that the people who
run these enterprises are loathe to admit (or often don’t even realise) that the level of complexity has grown beyond their ability to comprehend. This culture of denial is behind many of the management disasters of the information age – assumptions based on poor understanding of the key dependencies, weaknesses and bottlenecks in an organization have resulted in poor decision making. In the last few years, there has been a spate of corporate mergers of very large companies. The merged organizations each had their own cultures, processes, terminology and technology. Understanding how best to rationalise these organizations is only possible using models at an enterprise level – hence the recent upsurge in interest in EA. The benefits of EA are not always easy to measure – anyone with experience of change projects in large organizations can see that an EA approach is valuable, but it is hard to put a monetary figure on the benefits. Even just concentrating on tangible projects such as IT delivery, it is hard to put a figure on the benefits of EA. There are many opinions on why large IT projects tend to fail so spectacularly, but running through all of them are some key threads:

• Gaps in understanding – the business community are unable to elucidate their requirements to the technology providers, and the technology providers are unable to describe the impact of technology changes in such a way that the business community can understand the risk.
• Weakness of verbal requirements – written specifications are open to interpretation and contribute to gaps in understanding
• Lack of project cohesion – it is very difficult to coordinate a large development team to work towards a singular goal when their allotted tasks are specialised and isolated

It is clear that a well executed EA approach helps to overcome all these problems, but this still a “good feeling” rather than anything that can be measured. The only way to measure the benefits is to compare two almost identical projects, one which used an EA approach and one which did not.