How do you interpret Domains, Control Objectives and Controls in ISO 27001 standard?
ISO 27001 has for the moment 11 Domains, 39 Control Objectives and 130+ Controls. Following is a list of the Domains and Control Objectives.
1. Security policy
Information security policy
Objective: To provide management direction and support for information security in accordance with business requirements and relevant laws and regulations.
2. Organization of information security
Internal organization
Objective: To manage information security within the organization.
External parties
Objective: To maintain the security of the organization’s information and information processing facilities that are accessed, processed, communicated to, or managed by external parties.
3. Asset management
Responsibility for assets
Objective: To achieve and maintain appropriate protection of organizational assets.
Information classification
Objective: To ensure that information receives an appropriate level of protection.
4. Human resources security
Prior to employment
Objective: To ensure that employees, contractors and third party users understand their responsibilities, and are suitable for the roles they are considered for, and to reduce the risk of theft, fraud or misuse of facilities.
During employment
Objective: To ensure that all employees, contractors and third party users are aware of information security threats and concerns, their responsibilities and liabilities, and are equipped to support organizational security policy in the course of their normal work, and to reduce the risk of human error.
Termination or change of employment
Objective: To ensure that employees, contractors and third party users exit an organization or change employment in an orderly manner.
5. Physical and environmental security
Secure areas
Objective: To prevent unauthorized physical access, damage and interference to the organization’s premises and information.
Equipment security
Objective: To prevent loss, damage, theft or compromise of assets and interruption to the organization’s activities.
6. Communications and operations management
Operational procedures and responsibilities
Objective: To ensure the correct and secure operation of information processing facilities.
Third party service delivery management
Objective: To implement and maintain the appropriate level of information security and service delivery in line with third party service delivery agreements.
System planning and acceptance
Objective: To minimize the risk of systems failures.
Protection against malicious and mobile code
Objective: To protect the integrity of software and information.
Back-up
Objective: To maintain the integrity and availability of information and information processing facilities.
Network security management
Objective: To ensure the protection of information in networks and the protection of the supporting infrastructure.
Media handling
Objective: To prevent unauthorized disclosure, modification, removal or destruction of assets, and interruption to business activities.
Exchange of information
Objective: To maintain the security of information and software exchanged within an organization and with any external entity.
Electronic commerce services
Objective: To ensure the security of electronic commerce services, and their secure use.
Monitoring
Objective: To detect unauthorized information processing activities.
7. Access control
Business requirement for access control
Objective: To control access to information.
User access management
Objective: To ensure authorized user access and to prevent unauthorized access to information systems.
User responsibilities
Objective: To prevent unauthorized user access, and compromise or theft of information and information processing facilities.
Network access control
Objective: To prevent unauthorized access to networked services.
Operating system access control
Objective: To prevent unauthorized access to operating systems.
Application and information access control
Objective: To prevent unauthorized access to information held in application systems.
Mobile computing and teleworking
Objective: To ensure information security when using mobile computing and teleworking facilities.
8. Information systems acquisition, development and maintenance
Security requirements of information systems
Objective: To ensure that security is an integral part of information systems.
Correct processing in applications
Objective: To prevent errors, loss, unauthorized modification or misuse of information in applications.
Cryptographic controls
Objective: To protect the confidentiality, authenticity or integrity of information by cryptographic means.
Security of system files
Objective: To ensure the security of system files.
Security in development and support processes
Objective: To maintain the security of application system software and information.
Technical Vulnerability Management
Objective: To reduce risks resulting from exploitation of published technical vulnerabilities.
9. Information security incident management
Reporting information security events and weaknesses
Objective: To ensure information security events and weaknesses associated with information systems are communicated in a manner allowing timely corrective action to be taken.
Management of information security incidents and improvements
Objective: To ensure a consistent and effective approach is applied to the management of information security incidents.
10. Business continuity management
Information security aspects of business continuity management
Objective: To counteract interruptions to business activities and to protect critical business processes from the effects of major failures of information systems or disasters and to ensure their timely resumption.
11. Compliance
Compliance with legal requirements
Objective: To avoid breaches of any law, statutory, regulatory or contractual obligations, and of any security requirements.
Compliance with security policies and standards, and technical compliance
Objective: To ensure compliance of systems with organizational security policies and standards.
Information systems audit considerations
Objective: To maximize the effectiveness of and to minimize interference to/from the information systems audit process.
What is “The Open Group Architecture Framework (TOGAF)”?
The Open Group Architecture Framework, or TOGAF, is intended to provide a structured approach for organizations seeking to organize and govern their implementation of technology, particularly software technology. In that sense, its objective is to employ an encompassing conceptual framework to try to ensure that software development projects meet business objectives, that they are systematic and that their results are repeatable.
TOGAF was created and is maintained by The Open Group, an independent industry association. It builds on an earlier framework known as TAFIM, or Technical Architecture Framework for Information Management, originally devised by the U.S. Defense Dept. In early 2009, The Open Group released TOGAF version 9. The Open Group and others commonly lead TOGAF certification and educational programs today. Typically, enterprise architects lead use of TOGAF within organizations.
Like its TAFIM forerunner and many other frameworks, TOGAF owes a debt to the work of John Zachman, who created the Zachman Framework, a related schema to facilitate discussion between different software development stakeholders and improve software project and program outcomes. This and similar frameworks seek to effectively organize requirements gathering,to make sure what is built is what is needed. Zachman’s landmark work in the 1980’s while at IBM, brought context to the development process without endorsing a specific software language or methodology. Like TOGAF today, it clarified terms and roles, focusing on the ”What, How, When, Who, Where and Why” of technology implementation.
The basic TOGAF 9 document contains descriptions of an architecture development method and related techniques, an architecture content framework, an enterprise continuum, TOGAF reference models and a capability framework. Version 9 creates a model for extensibility, among other enhancements.
TOGAF need not be used ”whole hog.” While the basic TOGAF document runs to many pages, a pocket-book version is available too. Experienced professionals can focus on the aspects of TOGAF that work best for their organization as they pursue business benefits derived from software innovation.
TOGAF has enjoyed considerable adoption in organizations of diverse character. Its use is seen as a potential systematization of efforts – in the wake of high-profile failures – by governments, businesses and others to apply structured enterprise architecture principles to the still somewhat ”black arts” of software development and IT operations. TOGAF can be used with – or without – service-oriented architecture (SOA), UML and various frameworks, methodologies and tools of modern software development.
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.
What & How : Enterprise Architecture
List of Enterprise Application Architecture Patterns
Domain Logic Patterns: Transaction Script , Domain Model , Table Module, Service Layer .
Data Source Architectural Patterns: Table Data Gateway , Row Data Gateway, Active Record , Data Mapper .
Object-Relational Behavioral Patterns: Unit of Work , Identity Map , Lazy Load
Object-Relational Structural Patterns: Identity Field , Foreign Key Mapping ,Association Table Mapping , Dependent Mapping , Embedded Value ,Serialized LOB , Single Table Inheritance , Class Table Inheritance ,Concrete Table Inheritance , Inheritance Mappers .
Object-Relational Metadata Mapping Patterns: Metadata Mapping , Query Object, Repository .
Web Presentation Patterns: Model View Controller , Page Controller , Front Controller , Template View , Transform View , Two-Step View ,Application Controller .
Distribution Patterns: Remote Facade , Data Transfer Object
Offline Concurrency Patterns: Optimistic Offline Lock , Pessimistic Offline Lock, Coarse Grained Lock , Implicit Lock .
Session State Patterns: Client Session State , Server Session State ,Database Session State .
Base Patterns: Gateway , Mapper , Layer Supertype , Separated Interface , Registry , Value Object , Money , Special Case ,Plugin , Service Stub , Record Set
Example/sample ISO/IEC 27001:2013 ISMS scoping statements
Sample 1
The Information Security Management System (ISMS) applies to the provision of trusted and managed information security services to internal and external customers of <ORGANIZATION> in accordance with the ISMS Statement of Applicability revision xx, dated xx-xxx-xxxx
Sample 2
As stated in the Information Security Management System (ISMS) Statement of Applicability, revision xx, dated xx-xxx-xxxx, the ISMS encompasses <ORGANIZATION>’s Information Technology Division Office, Computer Lab, Storehouse and Computer Classroom, covering business activities relating to the provision of operation, maintenance and management of Internet and Web services and systems.
Sample 3
The provision of e-Business solutions that are fully integrated to deliver the complete process and management of e-Business components including: workflows; contacts; e-mail; bulletin boards; news; events; traffic analysis and audits on a secure hosted platform, 24 hours a day, 365 days a year, as per the Statement of Applicability approved by senior management on xx-XXX-xxxx.
Note: be aware that if you narrow the scope of your ISMS, you are also going to:
- Reduce the implementation costs to some degree, although you will still need to implement a comprehensive management system to be certified compliant to ISO/IEC 27001;
- Reduce the business benefits compared to a more broadly-scoped ISMS; and
- Have to define security interfaces for information flows and processes that span or extend beyond the in-scope area to the remainder, since everything outside the scoped area is relatively untrustworthy.
Mandatory requirements for ISO/IEC 27001:2013 certification
Mandatory requirements for certification
ISO/IEC 27001 is a formalized specification for an ISMS with two distinct purposes:
-
It lays out, at a fairly high level, what an organization can do in order to implement an ISMS;
-
It can (optionally) be used as the basis for formal compliance assessment by accredited certification auditors in order to certify an organization.
The following mandatory documentation (or rather “documented information” in the curiously stilted language of the standard) is explicitly required for certification:
-
ISMS scope (as per clause 4.3)
-
Information security policy (clause 5.2)
-
Information security risk assessment process (clause 6.1.2)
-
Information security risk treatment process (clause 6.1.3)
-
Information security objectives (clause 6.2)
-
Evidence of the competence of the people working in information security (clause 7.2)
-
Other ISMS-related documents deemed necessary by the organization (clause 7.5.1b)
-
Operational planning and control documents (clause 8.1)
-
The results of the risk assessments (clause 8.2)
-
The decisions regarding risk treatment (clause 8.3)
-
Evidence of the monitoring and measurement of information security (clause 9.1)
-
The ISMS internal audit program and the results of audits conducted (clause 9.2)
-
Evidence of top management reviews of the ISMS (clause 9.3)
-
Evidence of nonconformities identified and corrective actions arising (clause 10.1)
-
Various others: Annex A, which is normative, mentions but does not fully specify further documentation including the rules for acceptable use of assets, access control policy, operating procedures, confidentiality or non-disclosure agreements, secure system engineering principles, information security policy for supplier relationships, information security incident response procedures, relevant laws, regulations and contractual obligations plus the associated compliance procedures and information security continuity procedures.
Certification auditors will almost certainly check that these fifteen types of documentation are (a) present, and (b) fit for purpose. The standard does not specify precisely what form the documentation should take, but section 7.5.2 talks about aspects such as the titles, authors, formats, media, review and approval, while 7.5.3 concerns document control, implying a fairly formal ISO 9000-style approach.
Structure of the ISO/IEC 27001:2013 standard
ISO/IEC 27001:2013 has the following sections:
0 Introduction – the standard uses a process approach.
1 Scope – it specifies generic ISMS requirements suitable for organizations of any type, size or nature.
2 Normative references – only ISO/IEC 27000 is considered absolutely essential to users of ’27001: the remaining ISO27k standards are optional.
3 Terms and definitions – a brief, formalized glossary, soon to be superseded by ISO/IEC 27000.
4 Context of the organization – understanding the organizational context, the needs and expectations of ‘interested parties’, and defining the scope of the ISMS. Section 4.4 states very plainly that “The organization shall establish, implement, maintain and continually improve” a compliant ISMS.
5 Leadership – top management must demonstrate leadership and commitment to the ISMS, mandate policy, and assign information security roles, responsibilities and authorities.
6 Planning – outlines the process to identify, analyze and plan to treat information security risks, and clarify the objectives of information security.
7 Support – adequate, competent resources must be assigned, awareness raised, documentation prepared and controlled.
8 Operation – a bit more detail about assessing and treating information security risks, managing changes, and documenting things (partly so that they can be audited by the certification auditors).
9 Performance evaluation – monitor, measure, analyze and evaluate/audit/review the information security controls, processes and management system in order to make systematic improvements where appropriate.
10 Improvement – address the findings of audits and reviews (e.g. nonconformities and corrective actions), make continual refinements to the ISMS
Annex A Reference control objectives and controls – little more in fact than a list of titles of the control sections in ISO/IEC 27002. The annex is ‘normative’, implying that certified organizations are expected to use it, but they are free to deviate from or supplement it in order to address their particular information security risks.
Bibliography – points readers to five related standards, plus part 1 of the ISO/IEC directives, for more information. In addition, ISO/IEC 27000 is identified in the body of the standard as a normative (i.e. essential) standard and there are several references to ISO 31000 on risk management.
Why Enterprise Storage? How to deploy on-premise Enterprise Storage?
Enterprise storage is a broad category that includes products and services designed to assist large organizations with saving and retrieving digital information. Unlike consumer or small business storage devices, enterprise storage can handle large volumes of data and large numbers of users. It usually involves centralized storage repositories, such as storage area networks (SANs) or network-attached storage (NAS) devices.
Enterprise storage can be broken down into several categories. Primary storage houses the data that end users are actively accessing. Backup storage contains copies of the information in primary storage for use in disaster recovery situations or in other circumstances where a secondary copy is necessary. Backup storage is closely related to archive storage, which is where enterprises keep outdated information that needs to be saved for compliance or other purposes.
Whether on-premise or cloud deployment
Organizations can choose to purchase and deploy on-premises enterprise storage systems, or they can choose to store their data with an external cloud computing service. The advantage of on-premises enterprise storage is that the organization retains complete control of the hardware and data, satisfying some security and compliance concerns. On the other hand, cloud-bases enterprise storage simplifies storage management and may lower costs in some cases. Some companies take a hybrid approach and use a combination of both on-premise and cloud-based storage.
One of the key benefits of enterprise storage solutions is that they enable file sharing and collaboration among workers. Many offer security features, such as user-based permissions, that aren’t commonly found in consumer storage solutions. Enterprise storage also offers better performance, reliability, availability and scalability than other types of storage solutions.
Storage Networking and Management
Enterprise storage devices utilize similar technology as consumer and small business storage solutions. However, enterprise data storage generally offers higher reliability, availability and scalability. As a result, enterprise storage generally costs more than consumer or small business storage. It also usually requires more time and expertise to set up, while many consumer storage vendors takes a plug-and-play approach, and enterprise storage networks are typically run by specialized personnel or administrators.
Terms frequently associated with enterprise storage include storage networking, which is the linking of storage devices with each other and other computer systems, and storage management, which includes technology and processes that help organizations control and maintain their storage systems.
Enterprise Storage Implementation
When you decide to deploy a new enterprise storage system, you face a number of choices. First, you must decide whether to design and build your own storage system or to utilize a cloud-based storage service. If you decide to use a cloud computing service, you won’t have to make very many decisions about the hardware and network architecture, because the cloud vendor will handle those for you. Generally, the deployment steps for cloud storage will be fairly simple: Select a cloud service that meets your needs, sign up for the service and configure it to work with your existing applications and networks. Your most important task will be researching the services to make sure that you get one that can meet your needs and work with your current infrastructure.
How to deploy on-premise Enterprise Storage?
The following three steps for deploying on-premises storage networks involve setting up the physical hardware and cables, migrating data (if necessary), configuring the devices and testing the system.
1) Choose a Storage Media
If you decide to build your own storage system, you’ll have to make some additional decisions .For example, you’ll need to select which storage media to use: Tape, hard disk drives (HDDs) or solid state drives (SSDs). Tape is the least expensive medium, but its performance and capabilities generally make it suitable only for backup and archive applications. HDDs are more expensive than tape, but they offer the higher performance necessary for primary storage. SSDs cost the most of all, but they offer much better performance and reliability than either tape or HDDs. Many organizations use a mix of tape, HDDs and SSDs, and some storage devices themselves include a mix of HDDs and SSDs.
2) Choose a Storage Architecture
You’ll also need to decide on your storage architecture. Enterprise storage can include direct-attached storage (DAS), storage area networks (SANs) or network-attached storage (NAS) devices. DAS devices connect directly to an individual PC or server and don’t offer the same collaboration capabilities as networked storage. However, you do gain collaboration benefits from SAN and NAS devices. SANs provide block-level storage for access by servers, while NAS devices offer file-level storage for access by end users. Many organizations use a combination of DAS, NAS and SAN devices.
3) Choose a Network Protocol
You’ll also need to choose which network protocol you’ll use. Your options include the Internet Protocol Suite (TCP/IP), Fibre Channel Protocol (FCP) and Internet SCSI (iSCSI) protocol. The type of storage architecture you select will impact which network protocol(s) you can use. For example, Fibre Channel and iSCSI are SAN protocols, while NAS is an IP storage protocol. Fibre Channel over Ethernet (FCoE) has emerged as one way for Ethernet and Fibre Channel networks to converge.
Integration is the biggest challenge of Enterprise Architecture
When we think of working on Enterprise Architecture, we start with few common mistakes which if can be avoided then the journey ahead is relatively less complex.
1. We think it’s a technical problem. We think it is solvable by API, Web services, XML, enterprise resource planning or some other technology that changes every six months. Fat chance.
2. We haven’t truly tackled the problem. Over the years, we’ve defined the enterprise integration problem scope as order fulfillment then supply chain management, more recently customer relationship management and product lifecycle management. But really those are parts of the problem.
If you want to integrate the enterprise, then the scope of your problem is the whole enterprise. Arguably that’s a big, complex problem. But so is building a skyscraper, a planned community and the Panama canal. Your enterprise is everything from human resource management to marketing, manufacturing, distribution and finance and everything in between. That’s the scope of the enterprise integration problem.
3. We haven’t had a well-developed methodology for solving this problem. Enterprise architecture provides this methodology. Enterprise architecture provides a framework of principles, policies, models and standards.
The models break the enterprise down into distinct, manageable parts, one of the basics of problem solving. I’m not talking about the Holy Grail of reusable software components. I’m talking about the big picture. What are the business processes and data of the enterprise? And how do they fit together to create an integrated whole?
This is a thoughtful exercise, one best done by senior management with broad knowledge of the enterprise. Our enterprise “parts” are not arbitrary. If we do a good job, we will make it crystal clear what our enterprise “parts” are, where the integration points are, which ones should be common or standardized across our enterprise and which ones can be unique for each business unit.
For example, you may want common financial and HR business processes, but different manufacturing processes for each business unit. There is some brain-busting work that has to done in deciding what is in and out of each business process and how common you want that part of your enterprise to be. And it is critical to get the breakpoints between the parts right.
The principles, policies and standards of the enterprise architecture framework provide for some rigor and rules in how the individual parts are designed and built so that they will fit together in the end. All you third-party software developers out there, you’ll need to help us out by coming up with some standard definitions of your modules (parts) so you can become interchangeable. (Yes, we know this isn’t in your best interest). Don’t forget that the principles, policies and standards have to be developed not only for technology but also for data and business processes.
So…
First, let’s tackle the real integration problem: the enterprise. Second, let’s stop hoping that technology is going to solve the enterprise integration problem. Third, let’s use enterprise architecture to thoughtfully break the enterprise down into distinct, manageable parts and provide some principles, policies, models and standards so that we can turn people loose within an architected framework to integrate the enterprise.
Gartner Identifies Ten Enterprise Architecture Pitfalls
“Avoiding the pitfalls in the first place is much easier than climbing out of a hole you’ve inadvertently tumbled into,” said Scott Bittler, research vice president at Gartner. “Applying the ways to avoid these pitfalls results in achieving EA benefits faster and reduced risk of programme failure. It will also improve the credibility of IT among business leaders.”
The ten EA pitfalls include:
1. The Wrong Lead Architect: Gartner identified the single biggest EA problem as a chief architect who is an ineffective leader. He or she may understand EA well but has ineffective leadership skills that even a good organisational structure and staffing levels cannot overcome. Gartner recommends that such a lead architect be replaced by someone with strong ‘soft’ skills such as enthusiasm, communication and passion, as well as being well respected and strategically minded.
2. Insufficient Stakeholder Understanding and Support: This happens when employees outside the EA team don’t participate in the EA programme, EA content is not used in projects and management questions its value. Gartner’s solution is to make EA education and communication a top priority to secure executive-team sponsorship. “The key is to ‘sell’ first and architect later,” said Mr Bittler.
3. Not Engaging the Business People: When IT and business goals are not aligned, resultant problems include non-technical people trying to make technical decisions while enterprise architects become too reactionary and tactical in response to projects. To overcome this, Gartner recommends that enterprise architects get involved in the development of the business context and engage jointly with other employees in the business architecture.
4. Doing Only Technical Domain-Level Architecture: This dated EA approach is still in use in some organisations and is even narrower in scope than technical architecture. Holistic EA best-practice is much broader as it includes business, information and solutions architecture.
5. Doing Current-State EA First: Successful EA provides prescriptive guidance but current-state EA does not, so it delays delivery of EA value and hinders the creation of good future-state EA. “The temptation is often to do the easy – current-state – EA first,” said Mr Bittler. “Instead, establish the business context and then focus first on future-state EA.”
6. The EA Group Does Most of the Architecting: This is a pitfall because the EA content is typically off the mark as it was not informed by those on the business side. There is also consequently no buy-in for the EA. The primary job of architects is to lead the EA process rather than impose EA content on the organisation. They should form virtual teams to create content and seek consensus on the content.
7. Not Measuring and Not Communicating the Impact: The value of EA is often indirect, so it may not be obvious to everyone in the organisation. This then exposes the EA programme to risk of failure. Gartner recommends that enterprise architects create a slide to demonstrate each success story of EA applied to a project. They should include measurement and documentation of EA in the programme plan.
8. Architecting the ‘Boxes’ Only: Enabling better business agility and integration is key but architecting standards for the ‘boxes’ (business units) in process, information, technical and solutions models doesn’t address this. Integration and interoperability standards are high EA priorities and must account for more than just technical architecture. Architects should focus more on the links between the boxes.
9. Not Establishing Effective EA Governance Early: Enterprisearchitects must resist the temptation to wait for more architecture content before setting governance processes and instead develop content and governance in parallel.
10. Not Spending Enough Time on Communications: Key messages about EA are not intuitively obvious, so enterprise architects must work to educate the business. It is critical that organisations develop and execute an EA communications plan with messages tailored to each audience.
“The key for enterprise architects is to create not the perfect or most elegant architecture for the moment, but the most adaptable architecture for the future,” said Mr Bittler. “EA is a challenging discipline and careful attention to the basics can mean the difference between failure and success.”
Top IT Service Management challenges…
- IT cost transparency. Something has still got to give in terms of what IT costs — IT is and will continue to be a sizable expense to the business. The IT organization is spending the business’ money, and so the business wants to know whether it is being spent wisely (and who can blame them). How many IT shops know if they are investing the business’ money wisely outside of projects?
- Value demonstration. Is IT still just a cost center or has your IT organization been able to translate IT investment into demonstrable business success? I still rather somewhat cheekily say that “if we could demonstrate the business value derived from IT, surely we would be being asked to spend more rather than having to respond to corporately mandated, quick fix, end-of-year budget cuts.”
- Agility. The speed of business change continues to dictate a rapid response from IT that many struggle with — as a simple example, yesterday my nephew told me of his five-week wait for a laptop at the bank he recently joined. Not only is it speed and flexibility, it is also “agility of mind.” A change in I&O mindset that asks “why not?” rather than “why?”
- Availability. Nothing new here (again). The business needs high quality, highly available IT (or business) services. The difference is in business expectations and available alternatives. For a number of reasons, the business continues to be less forgiving of IT failure and, again, who can blame them.
- “Personal hardware.” End user devices will continue to be a big challenge for IT in 2013. Whether it is the fact that our “internal customers” are unhappy with their “outdated” corporate laptops or the fact that they can’t have corporate iPads or the whole “can of worms” that is BYOD (bring your own device), personal productivity hardware will again be a battleground of business discontent in 2013.
- Support and customer service. For me, support is one thing and customer service is another; ideally IT delivers both. That it is ultimately about supporting the consumption of IT services by people rather than just supporting the technology that delivers the IT services. And that service-centricity by frontline IT staff is not enough; it needs to be all IT staff. The same is true for customer-centricity.
- Cloud. As cloud adoption continues, are we looking at cloud as a technical or business solution, or both? Do we know enough about the status quo to make informed decisions about moving IT services to the cloud? Probably not; yet for many, cloud is the answer. But I still can’t help think that we haven’t really taken the time to fully understand the question.
- Mobility. BYOD comes into play here again, but I think that a bigger issue is at hand — that we are still technology-centric. We all hear talk about MDM (mobile device management) as “THE big issue.” IMO, however, this is old-skool-IT with the device a red herring and of little interest to the customer (unless IT is providing outdated devices). Your customers want (or at least we hope that they continue to want) to access your services any which way they can and need to. Mobility is about people.
- Compliance. Whether it’s internal or external regulatory compliance (or governance), most of the above will potentially have a negative knock on to compliance whether it be SOX, software compliance, or meeting internal requirements for “transparency and robustness.” With everything going on elsewhere, it is easy for me to imagine degradation in internal control, not reacting to new risks as a minimum.
How can organisations using ITIL adapt for Cloud Services?
The first point to make here, is that ITIL is, and will continue to be, an IT Service Management toolkit.
That means that you don’t have to be using ALL of ITIL, ALL of the time – the methodology can be adapted to suit the needs of organisations – the key thing is to put your organisational requirements first, and not follow bureaucracy for the sake of it.
Second, ITIL has been formed on IT Service Management best practice and will continue to evolve to reflect the needs of IT departments the world over.
Public vs Private Clouds:
Well run IT service Management systems have always had to apply different models to different systems – they will continue to evolve, The focus if IT teams will have to move away from operational aspects of infrastructure to managing the diverse environments that public, private and hybrid Cloud environments will bring.
Configuration Management Database:
Anyone who uses ITIL will know the importance of the CMDB – however doesn’t necessarily mean inflexibility. A well implemented CMDB can make things more agile in fact.
No doubt, the way organisations use the configuration management database will need to be tweaked for Cloud – however the message is the same – use ITIL as part of a sensible and flexible IT Service Management infrastructure and you will be able to account for any changes that new technology brings.
What issues does ITIL face with Cloud Computing?
Some of the problems that ITIL will face with Cloud Computing include:
- Because Cloud and SaaS apps are based on a pay-as-you-go model, they have the potential to operate under the radar of ‘traditional’ IT service management infrastructure – particularly with relation to procurement
- Dealing with Private and Public cloud services will require different approaches. Public clouds are great in terms of their cost savings but cab be less reliable, especially when you look at security, compliance and service level agreements. These problems are not there with Private cloud services – but they don’t come cheap. As a result, many organisations use hybrid services.
- ITIL’s configuration management database (CMDB) – is designed to hold information about assets and resources that exist in an IT environment – what happens when those resources don’t physically exist any more?!