Security Maturity Model v0.85

Página 1 de 24

Security Maturity Model Draft v0.85 © Vicente Aceituno – 2004. An ISECOM Project Open Content Licensed.

Página 2 de 24

Table of Contents 1 Introduction .....................................................................................................................................4 2 SMM Concepts ...............................................................................................................................6

2.1 Quality .......................................................................................................................... 6 2.2 Security in Context Model ............................................................................................ 6 2.3 Organization Model...................................................................................................... 8

2.3.1 Structure.............................................................................................................. 8 2.3.2 Behaviour ............................................................................................................ 8

2.4 Information System Model ........................................................................................... 8 2.4.1 Structure.............................................................................................................. 9 2.4.2 Behaviour ............................................................................................................ 9

2.5 Zones ........................................................................................................................... 9 2.6 Information Security Management Model .................................................................... 9

2.6.1 Plan ................................................................................................................... 10 2.6.1.1 Scope............................................................................................................ 10

2.6.1.1.1 Assets Evaluation .................................................................................... 10 2.6.1.1.2 Inventory Management............................................................................ 10 2.6.1.1.3 Classify Repositories and Messages. ..................................................... 10 2.6.1.1.4 Prioritise Repositories, Interfaces, Services and Networks..................... 10 2.6.1.1.5 Value Physical Components, Repositories, Interfaces, Services and Networks. 10

2.6.1.2 Targets .......................................................................................................... 11 2.6.1.2.1 Expectations Evaluation .......................................................................... 11 2.6.1.2.2 Organizational Expectations Evaluation.................................................. 11 2.6.1.2.3 Privacy Evaluation ................................................................................... 11 2.6.1.2.4 Legal Evaluation ...................................................................................... 11 2.6.1.2.5 Intellectual Property Evaluation............................................................... 11

2.6.1.3 HowTo........................................................................................................... 11 2.6.1.4 Commitments................................................................................................ 12 2.6.2 Do...................................................................................................................... 12 2.6.2.1 Protection of Information Systems Lifecycle................................................. 12

2.6.2.1.1 Interfaces and Repositories Hardening ................................................... 12 2.6.2.1.2 Network and Services Hardening............................................................ 12 2.6.2.1.3 Services Patch Management................................................................... 12 2.6.2.1.4 Services (Applications) Development Protection .................................... 12

2.6.2.2 Security Measures Lifecycle Management ................................................... 12 2.6.2.2.1 Services and Repositories Access Control ............................................. 12 2.6.2.2.2 Malware Protection.................................................................................. 12 2.6.2.2.3 Network (and Zones) Filtering Management ........................................... 12 2.6.2.2.4 Redundancy & Backup Management...................................................... 13 2.6.2.2.5 PKI and Encryption Management............................................................ 13 2.6.2.2.6 Physical and Environmental Protection................................................... 13 2.6.2.2.7 Insurance................................................................................................. 13 2.6.2.2.8 Continuity of Operations .......................................................................... 13

2.6.3 Check ................................................................................................................ 13 2.6.3.1 Test ............................................................................................................... 13

2.6.3.1.1 Attacks, Errors and Accidents Emulation ................................................ 13 2.6.3.1.2 Incidents Emulation ................................................................................. 13 2.6.3.1.3 Independent Audits.................................................................................. 13

2.6.3.2 Monitor .......................................................................................................... 14 2.6.3.2.1 Discovery of new Weaknesses................................................................ 14 2.6.3.2.2 Incidents and Intrusions Detection .......................................................... 14

2.6.3.3 Audit .............................................................................................................. 14 2.6.4 Act - Incidents Management ............................................................................ 14

2.6.4.1.1 Incidents and cuasi-Incidents Handling................................................... 14 2.6.4.1.2 Forensics ................................................................................................. 14

2.6.5 Budget Management ......................................................................................... 14 2.6.5.1 Burget Allocation........................................................................................... 14 2.6.5.2 Return on Security Investment...................................................................... 15

Página 3 de 24

2.6.5.3 Practices and Security Measures Selection. ................................................ 15 2.6.6 People Management ......................................................................................... 15 2.6.6.1 Background Check of Personnel .................................................................. 15 2.6.6.2 Selection of Security Personnel .................................................................... 15 2.6.6.3 Training on Security ...................................................................................... 15 2.6.6.4 Personnel Layoff ........................................................................................... 15 2.6.6.5 Security Awareness ...................................................................................... 15

3 SMM Levels ..................................................................................................................................16 3.1 Degree of Competency .............................................................................................. 16 3.2 SMM Level 1 - Initial .................................................................................................. 16 3.3 SMM Level 2 - Acknowledged ................................................................................... 16 3.4 SMM Level 3 - Defined .............................................................................................. 17 3.5 SMM Level 4 - Managed............................................................................................ 18 3.6 SMM Level 5 - Optimum ............................................................................................ 19

4 SMM Handling ..............................................................................................................................21 4.1 SMM Auditing............................................................................................................. 21 4.2 SMM Planning............................................................................................................ 21 4.3 SMM Certification....................................................................................................... 21

5 References ...................................................................................................................................21 6 Acronyms......................................................................................................................................21

6.1 CIA ............................................................................................................................. 21 6.2 ISM............................................................................................................................. 21 6.3 PKI ............................................................................................................................. 21 6.4 SMM........................................................................................................................... 21

7 Glossary & Terminology................................................................................................................21 7.1 Accident ..................................................................................................................... 21 7.2 Asset .......................................................................................................................... 22 7.3 Aspect ........................................................................................................................ 22 7.4 Attack ......................................................................................................................... 22 7.5 Catastrophe................................................................................................................ 22 7.6 Critical ........................................................................................................................ 22 7.7 Environment ............................................................................................................... 22 7.8 Error ........................................................................................................................... 22 7.9 Evaluation .................................................................................................................. 22 7.10 Expectation ................................................................................................................ 22 7.11 Incident....................................................................................................................... 22 7.12 Interface ..................................................................................................................... 22 7.13 Impact ........................................................................................................................ 23 7.14 Intrusion ..................................................................................................................... 23 7.15 Management .............................................................................................................. 23 7.16 Message..................................................................................................................... 23 7.17 Network ...................................................................................................................... 23 7.18 Opportunity................................................................................................................. 23 7.19 Process ...................................................................................................................... 23 7.20 Quality ........................................................................................................................ 23 7.21 Resource.................................................................................................................... 23 7.22 Responsibility ............................................................................................................. 24 7.23 Repository .................................................................................................................. 24 7.24 Risk ............................................................................................................................ 24 7.25 Role............................................................................................................................ 24 7.26 Security ...................................................................................................................... 24 7.27 Security Requirement ................................................................................................ 24 7.28 Service ....................................................................................................................... 24 7.29 Threat......................................................................................................................... 24 7.30 Vulnerability................................................................................................................ 24 7.31 Weakness .................................................................................................................. 24 7.32 Zone ........................................................................................................................... 24

8 Typographical Conventions ..........................................................................................................24

Página 4 de 24

1 Introduction Whereas information systems security research focus mainly on technical issues, many other critical aspects of information security lag behind in terms of body of knowledge and methodology. The security of an organization depends on:

• Structure and Behaviour of the Organization. • Security Planning. • Management of Security Measures. • Protection of Information Systems Lifecycle. • Security Checking. • Incidents Management • Resources Management (People, Information, Money, Time).

A good example of a non-technical security problem was Barings Bank bankruptcy in 1995. An employee was assigned an unchecked responsibility with an economic impact. Traditional systems auditing can tell how secure are an organization’s information systems now. But secure information systems don’t stay secure for long in insecure organizations, where:

• Responsibilities are badly assigned or checked. • There is no formal security organization. • Security targets are unknown. • The security budget is spent in fashionable security measures.

With a maturity model, organizations can determine how secure they are, this is, how capable they are to stay secure for themselves. Partial results of achieving the higher SMM Levels shouldn’t depend on external contractors but for independent audits. To achieve the appropriate SMM levels will give many benefits, such:

• Improve customer and stockholder’s trust on the organization. • Maximize turnover of security investment. • Avoid non-technical security risks, setting an environment where there are no weak

links. The SMM should tackle some of the most difficult aspects of information security management and avoid some pitfalls of current models, as pointed by Mikko Siponen in his paper “Towards maturity of software maturity criteria”.

• SMM reuses existing knowledge via “recognized methodologies”. These methodologies are map able to CMMI, BS17799-2 and the CISSP Domains, reflecting the current best practice. Checking for compliance with these methodologies might lead to checking for SMM compliance.

• SMM is not a “one-size-fits-all” methodology. To suit both stable and emergent organizations, the CIA model is dropped for the SIC model (Security In Context). The SIC model focuses on the particular key areas for every organization, preventing looking only at predefined spots. This should help to find out “How much security is enough?” Instead of considering CIA as the target of ISM, prevention and palliation of incidents is paramount. What an incident is depends on the organizational expectations.

• SMM applies the Quality Management’s Plan-Do-Check-Act approach to Information Security Management.

• SMM achieves a holistic view of the Organizations using Physical, Logical and Organizational aspects.

• SMM is scalable integrating the use of Zones on every aspect with ISM. • SMM doesn’t follow a positivistic point of view where cause follows invariably effect and

mathematical models can predict correctly the behaviour of the organization. • It uses a simple and richer information system model.

Página 5 de 24

SMM is not a process improvement model; one of the targets is the reuse of existing knowledge. Security management processes are still a moving target; any particular definition of any practice would render the model quickly outdated.

Página 6 de 24

2 SMM Concepts 2.1 Quality Quality can be considered as the meeting or surpassing a set of expectations. Whereas Quality is falsable (as defined by Popper), Security is not falsable. When expectations are met, we can show quality. If expectations aren’t met, there isn’t quality. When expectations are met many times, we can show security up to a certain date but, What about next time? We can know when there isn’t security, but we can’t know when there is security. The best-known Total Quality Management paradigm is PDCA (Plan-Do-Check-Act)

2.2 Security in Context Model Good definitions help to prevent miscommunication and facilitate understanding of related concepts. With a good definition it is easier to move from theory to practice. Different sources use three to five of these terms, with more or less precision.

• Confidentiality. • Integrity. • Availability. • Access Control. • Non-repudiation.

The main defects of this definition are:

• It is an out of context definition. • The many exceptions show that this traditional definition doesn’t help to move from

theory to practice: o Confidentiality. (Can’t apply to public repositories and messages) o Integrity. (Can’t apply to fault-tolerant repositories and messages) o Access Control. (Can’t apply to anonymous services and repositories) o Non-repudiation. (Can’t apply to friendly messages) o Availability. (Can’t apply to low priority repositories)

• It assumes protection against Malicious Attacks only. It doesn’t consider other security problems, like Errors and Accidents. (Errors, copyright protection, fraud protection, legal protection, theft, uncontrolled information persistence, loss of synch)

The CIA approach to security is “We want to prevent attacks from succeeding”. With this approach, to be secure means to be invulnerable. Under CIA viewpoint, an incident is a deviation of confidentiality, integrity or availability. To reach a compromise is called “accepted risk”. A better definition should:

• Be context dependent • Have no exceptions. • Encompass errors, accidents and attacks • Relate to other concepts. • Help to go from theory to practice.

A better approach is “We want to guarantee that out targets are met”. With this approach, to be secure means to be reliable, despite of attacks, accidents and errors. Under SIC viewpoint, an incident is a deviation of the Business expectations. You don’t reach compromises; you aim for solutions that optimize ROSI. The Security in Context alternative, improved, definition for security is: “Security is the result of the continuous meeting or surpassing of a set of expectations.”

Página 7 de 24

Let’s see two examples to show how this definition works in context:

A Company’s expectations: • Achieve the organization’s mission. • For businesses, profitability. • The organization continued existence. • Comply with regulations and contracts.

Home user expectations:

• My passwords and secrets are not revealed. • My hard disk won’t break. • Only people with access to my home can use my computer.

There are no exceptions to be considered when this definition is used:

• The expectation for public information is for it to be public. • The expectation for fault-tolerant information is to tolerate faults. • The expectation for anonymous services is not to identify users. • The expectation for friendly messages is honesty. • The expectation for low priority information is best effort availability.

This definition encompasses Attacks, Errors and Accidents;

• We expect not to be affected by malicious agents. • We expect to prevent or correct human and systems mistakes. • We expect to overcome natural and random mishaps.

Using this definition is easy to see that security measures and security are not the same. Security measures just make our expectations more likely to be met. Security Requirements can be easily derived from a set of Expectations, as shown in the following:

• Attacks: We expect not to be affected by malicious agents. o “In the case of a successful attack, our critical systems should

completely recover in one hour.” o “The sales department will check client’s credit”. o “All valuable physical assets will be permanently marked with the

company logo and a serial number”.

• Errors: We expect to prevent or correct human and systems mistakes. o “User interfaces must present a confirmation screen for all economic or

customer-visible actions.” o “Users must use only copyrighted software”. o “Software licences must be reviewed by the legal department”. o “Hard drives will be physically destroyed at their end of life”.

• Accidents: We expect to overcome natural and random mishaps.

o “Power outages shorter than 2 hours mustn’t impact critical systems”. o “No data centre will be located on a flood-prone area”.

Due to this context-dependent security definition, SMM should be applicable to any organization. Only security practices and security measures consistent with the organization’s expectations should be implemented.

Página 8 de 24

2.3 Organization Model

2.3.1 Structure From a structure point of view, organizations can be modelled as:

• A border that defines the limits of the organization. • Roles: Sets of responsibilities assigned to a person or a team. It is the smallest

organizational component. • Organizational chart that defines supervision responsibilities between roles.

The structure of the organization plays a fundamental role in security, as a faulty structure can’t be fixed with technical or procedural means. Security Principles:

• Responsibilities partitioning. All responsibilities must be assumed by one and only one role. No responsibility should be left unassigned.

• Supervision of Duties: Control: For every role there should be another role with the responsibility to check and supervise actively or passively the performance of the first.

• Efficiency: One to one relationship between power, competency and responsibility. Any role that has an assigned responsibility must have the competency, resources and power to make it effective.

• All security-related responsibilities are assigned. Not all security-related responsibilities belong to security roles. Many roles in the organization will have certain security responsibilities within their area of competence.

The security organization is the part of the organization that holds mainly security responsibilities.

2.3.2 Behaviour From a functional point of view, organizations can be modelled as Organizational Processes. Organizational processes are safer when there is an end-to-end trail of the process when the process uses or produces critical resources. Critical resources can be money, image, information or manpower. but what a critical resource is depends on the organization. Processes output can be products or services. Security Principles:

• Rotation of Duties: No person should hold a responsibility indefinitely (or even predictably). For example, the person in charge of auditing should change from one audit to the next.

• Separation of Duties: No person should carry a sensible process from end to end, or hold incompatible roles. No role can hold incompatible responsibilities. An example of a clear incompatibility is to perform a task with and economic impact and keep record of it.

2.4 Information System Model A poor object model for information systems plagues the field of security of information systems. The current model for information systems has a single complex object “Information”. The complex structure and behaviour of information systems is sometimes utterly ignored in Information Security theories, and sometimes expressed in awkward ways, like “Information in transit” for communications. Using the SMM information system model, many fundamental properties of Information Systems become available for method developers. Whereas from a logical point of view this model fits very well, from a physical point of view components are a complex mix of these logical objects.

Página 9 de 24

2.4.1 Structure • Repositories. Any temporal or permanent storage of information, including RAM,

databases, file systems and removable media. • Interfaces. Any input/output device, like screens, printers and fax. • Networks. The physical or logical interconnection of components, including buses, LAN

networks, etc. • A border that defines the limits of the system.

2.4.2 Behaviour • Services. Any “value” provider in an information system, including services provided by

BIOS, operating systems and applications. A service can collaborate with other services or lower level services to complete a task that provides a value.

• Messages. Any meaningful information exchanged between two services or a user and an interface.

2.5 Zones Zones define inner borders that partition the logical, physical or organizational whole of the organization in chunks with uniform expectations. Zones have their own expectations, requirements and security measures. Zones simplify security management allowing for security norms adapted to specific expectations. The borders of the zones are known; so effective filtering of messages, services, people and assets becomes possible. Using division in zones and filtering between them reduces the opportunities of an attack, accident or error. A successful attack in a certain zone shouldn’t affect others. Zones define inner borders that partition the logical, physical or organizational whole of the organization in chunks with uniform expectations. Physical Zones can be partitioned depending on the criticity of the assets they hold. Logical Zones can be partitioned beyond the traditional DMZ / Trusted Zone dichotomy to match physical and organizational zones. The more organizational, technical and physical zones match, the easier it becomes to protect them from attacks, errors and accidents.

2.6 Information Security Management Model To manage something means:

• Define and Achieve Targets. • Optimise the use of Resources.

Information Security Management should follow the PDCA paradigm when defining and achieving targets within the environment of the organization. As any other responsibility, IS Management can be shared with others, or can be taken by a team instead of an individual. Information Security Management (ISM) mission is:

• Prevent and Palliate Incidents that could jeopardize the organization’s output of products and services that rely on information systems via:

o Protection and support of the information systems along their lifecycle.

Página 10 de 24

o Management of the lifecycle of security measures. • Optimise the use of information, money and people; time and infrastructure.

Information Security Managers must coordinate their efforts with other managers of company resources, such as Human Resources, Infrastructure, Financial or Information Systems. The following diagram summarize the SMM ISM:

2.6.1 Plan

2.6.1.1 Scope The following activities help to define the scope of ISM.

2.6.1.1.1 Assets Evaluation Assets Evaluation identifies, classifies, prioritises and value assets quantitatively. This information is an important resource for selection of security measures and optimising the security investment.

2.6.1.1.2 Inventory Management • Recognized methodologies:

(In development)

2.6.1.1.3 Classify Repositories and Messages. • Recognized methodologies:

(In development)

2.6.1.1.4 Prioritise Repositories, Interfaces, Services and Networks. • Recognized methodologies:

(In development)

2.6.1.1.5 Value Physical Components, Repositories, Interfaces, Services and Networks. • Recognized methodologies:

(In development)

Information SystemsLifecyle Protection

Security MeasuresManagement

People Management

Budget Management

IncidentsManagement

Do CheckPlan

Targets:Policy

How To:Procedures

Commitments:Agreements

Scope:Inventory

Monitor

Test

Audit

Act

Organization Structure & Processes

Página 11 de 24

2.6.1.2 Targets The following activities help to define the context and organization-dependent target of ISM. Expectation driven targets guarantee that high expectations for some organizational units don’t force all the organization to follow security practices and measures that are inconvenient for unrelated activities. A good example are some organizations where to get admin rights to an empty database used for internal development only needs a security clearance.

2.6.1.2.1 Expectations Evaluation Expectations Evaluation identifies, classifies and prioritises expectations. This information is an important resource for the security norms framework, where these expectations are turned into specific requirements.

• Security Policy: A Security Policy describes the high-level principles that describe the targets (why) and the strategies (what) to reach them.

• Zone Policy: The Zone Policy develop the strategies describing the scope (where and when) of the security practices.

The most frequent evaluation nowadays is Risk Evaluation. Risk evaluation is complementary to Expectations Evaluation. Whereas Risk Evaluation tries to identify the things we don’t want to happen, Expectations Evaluation tries to identify the things we want to happen. If the organization feels the need to do Risk Evaluation, it can use one of the following recognized methodologies:

• Recognized methodologies: o OCTAVE.

2.6.1.2.2 Organizational Expectations Evaluation • Recognized methodologies:

(In development)

2.6.1.2.3 Privacy Evaluation • Recognized methodologies:

(In development)

2.6.1.2.4 Legal Evaluation • Recognized methodologies:

(In development)

2.6.1.2.5 Intellectual Property Evaluation • Recognized methodologies:

(In development)

2.6.1.3 HowTo Security Procedures develop standards and norms and give a step-by-step description of the who and how of the practice. A procedure should define:

• What it is for. • Who and How should apply the procedure. • Responsibilities on compliance with the procedure. • Who can modify the procedure. • Forms and related communication media. • A description of tasks, including who, what, when, acceptable response time, when the

procedure is considered to start and to finish. • Escalation and conflicts resolutions.

Operations Continuity Procedure (Plan) specifies how to act when a catastrophe happens.

Página 12 de 24

2.6.1.4 Commitments Documents that express security commitments / Contractual Information.

• Acceptable use Policy /Fair use norm: informs users about their obligations when using the organization’s information systems.

• Third party agreement: The Third Party Agreements define mutual security commitments at the organization’s borders with others.

2.6.2 Do

2.6.2.1 Protection of Information Systems Lifecycle When security requirements are considered starting at the Analysis Phase, the resulting Information Systems are inherently secure, saving in additional security measures. As information systems lifecycle maintenance will normally be a responsibility of the information systems department, it is a responsibility of the security organization to support this department on helping the information systems to be as secure as needed through their lifecycle.

2.6.2.1.1 Interfaces and Repositories Hardening • Recognized methodologies:

(In development)

2.6.2.1.2 Network and Services Hardening • Recognized methodologies:

(In development)

2.6.2.1.3 Services Patch Management • Recognized methodologies:

(In development)

2.6.2.1.4 Services (Applications) Development Protection • Recognized methodologies:

(In development)

• List or recognized methodologies: o SPSMM - Secure Programming Standards Methodology Manual. o OWASP (For web applications). o STICK - Software Testing Checklist.

2.6.2.2 Security Measures Lifecycle Management Security measures complement information systems security features. The security organization supports their lifecycle from selection to installation, operation and decommissioning.

2.6.2.2.1 Services and Repositories Access Control • Recognized methodologies:

(In development)

2.6.2.2.2 Malware Protection • Recognized methodologies:

(In development)

2.6.2.2.3 Network (and Zones) Filtering Management Firewalls can be deployed in the borders between Logical Zones.

• Recognized methodologies: (In development)

Página 13 de 24

2.6.2.2.4 Redundancy & Backup Management • Recognized methodologies:

(In development))

2.6.2.2.5 PKI and Encryption Management • Recognized methodologies:

(In development)

2.6.2.2.6 Physical and Environmental Protection • Recognized methodologies:

(In development)

2.6.2.2.7 Insurance • Recognized methodologies:

(In development))

2.6.2.2.8 Continuity of Operations A mature organization will normally protect itself from catastrophes with an appropriate continuity of operations infrastructure. It is the responsibility of the security organization to maintain it.


2.6.3 Check Checking practices provide a critical resource for Planning and Doing: Information.

2.6.3.1 Test

2.6.3.1.1 Attacks, Errors and Accidents Emulation The emulation of attacks enable to validate the effectiveness of vulnerability reduction security measures.


2.6.3.1.2 Incidents Emulation The emulation of incidents enable to validate the effectiveness of impact reduction security measures. When the emulated incident is a catastrophe, the Operations Continuity Procedure is validated.


2.6.3.1.3 Independent Audits Independent audits are the natural consequence of the separation of duties principle. While incidents and attacks emulation can validate our security measures, independent audits are key to uncover potential errors in the performance of the security organization.

• Recognized methodologies: OSSTMM - Open Source Security Testing Methodology Manual.

Página 14 de 24

2.6.3.2 Monitor To monitor security measures and information systems operation helps to detect intrusions and incidents. Some monitoring is done in real time, some takes analysis of behaviour and state of services, repositories and networks.

2.6.3.2.1 Discovery of new Weaknesses • Recognized methodologies:

(In development)

2.6.3.2.2 Incidents and Intrusions Detection • IDS, IPS, etc. • Logs analysis. • SNMP Monitoring.

2.6.3.3 Audit • Recognized methodologies:

(In development)

2.6.4 Act As absolute security is not possible, incidents happen. Managing incidents will contain their effects. The information gathered will help the organization to learn from mistakes and have some hard data available to evaluate their security investment efficiency. To gather information on incidents, intrusions and close calls provide a fundamental resource to improve the operation of security measures, take decision on security investment, measure the efficiency of security measures, etc.

2.6.4.1.1 Incidents and cuasi-Incidents Handling Incidents handling defines the reaction to detected incidents, the contention measures, and real time gathering of information. Incidents Handling should pave the way for Forensics if necessary.

• Recognized methodologies: SIPES - Security Incident Policy Enforcement System.

2.6.4.1.2 Forensics Forensic assessments after an incident give valuable information on the innards of incidents. The evidence gathered, put together with the information collected during the incident evidence enable the eventual prosecution of attackers and diagnosis of the incident.


2.6.5 Budget Management The information gathered on incidents and close calls can gauge the efficiency of the security measures. With this information it should be possible to select the best security measures with the available budget and request additional funds if necessary.

2.6.5.1 Budget Allocation • Recognized methodologies:

(In development)

Página 15 de 24

2.6.5.2 Return on Security Investment • Recognized methodologies:

(In development)

2.6.5.3 Practices and Security Measures Selection. • Recognized methodologies:

(In development)

2.6.6 People Management A secure organization members are competent and trustable people.

2.6.6.1 Background Check of Personnel Background checking should guarantee that new employees don’t mean a risk to the organization.


2.6.6.2 Selection of Security Personnel The selection process should guarantee the competency, knowledge and experience of the new employees to perform security duties. Certifications can help on this matter.

• List of recognized security certifications: o CISA. o CISSP. o OPST - OSSTMM Professional Security Tester Certification. o OPSA - OSSTMM Professional Security Analyst Certification. o OPSS - OSSTMM Professional Security Series.

2.6.6.3 Training on Security Training on security ensures that the security personnel improve their competency and stay up to date.


2.6.6.4 Personnel Layoff The use of personnel layoff procedures should mitigate the risks involved in this process.


2.6.6.5 Security Awareness Information Security needs the collaboration of all. As IS knowledge is not the primary interest of non-specialist, information on the subject can be disseminated in the organization to foster the collaboration of all organizational components.


Página 16 de 24

3 SMM Levels To get a “ Y” on the evaluation table the organization must show:

• That it complies with recognized methodologies for the practice with at least “Implemented” competency and;

• That it has been determined that the remaining practices are not consistent with the organizational expectations and maturity target. Related risks are deemed as acceptable and should be documented in the Security Policy, if there is one.

Organizational Structure and Processes Security represents the only difference between levels 4 and 5. Plan Do Check Act S&P

Security Level 1 N N N N Maybe Level 2 N Y Maybe Maybe Maybe Level 3 Y Y N Maybe Maybe Level 4 Y Y Y Y N Level 5 Y Y Y Y Y

3.1 Degree of Competency The organization can be more or less competent on any practice’s realization.. Initial Managed Defined Quantitatively Managed Optimizing For every practice a list of recognized methodologies will be given. The use of these methodologies should guarantee that the planned practices are competently performed.

3.2 SMM Level 1 - Initial

Security is not acknowledged as a desirable property of the organization. The absence of incidents is the result of luck or individual efforts. The presence of incidents invariably leads to the maximum impact that could be expected. While some practices can be found on this maturity level, there will be none supported by the organization’s management.

3.3 SMM Level 2 - Acknowledged Security is acknowledged as a desirable property of the organization. The absence of incidents is the result of luck or some organizational efforts. The presence of incidents doesn’t always lead to the maximum impact that could be expected. The results of the organizational efforts fades with time. Some of the following practices are followed:

Página 17 de 24

• Do Protection of Information Systems Lifecycle Interfaces and Repositories Hardening Network and Services Hardening Services Patch Management Services (Applications) Development Protection Security Measures Lifecycle Management Services and Repositories Access Control Malware Protection Network (and Zones) Filtering Management Redundancy & Backup Management PKI and Encryption Management Physical and Environmental Protection Insurance Continuity of Operations

3.4 SMM Level 3 - Defined Security is acknowledged as a desirable property of the organization. The absence of incidents is the result of luck or continuous organizational efforts. The presence of incidents normally doesn’t lead to the maximum impact that could be expected. The results of the organizational efforts are permanent. All of the following practices are followed or determined to be irrelevant to the organization’s expectations and environment: • Plan

Scope • Assets Evaluation • Inventory Management • Classify Repositories and Messages • Prioritise Repositories, Interfaces, Services and Networks • Value Physical Components, Repositories, Interfaces,

Services and Networks Targets

• Expectations Evaluation • Organizational Expectations Evaluation • Privacy Evaluation • Legal Evaluation • Intellectual Property Evaluation

HowTo Commitments

• Do Protection of Information Systems Lifecycle

• Interfaces and Repositories Hardening • Network and Services Hardening • Services Patch Management • Services (Applications) Development Protection

Security Measures Lifecycle Management • Services and Repositories Access Control • Malware Protection • Network (and Zones) Filtering Management • Redundancy & Backup Management • PKI and Encryption Management • Physical and Environmental Protection • Insurance • Continuity of Operations

Página 18 de 24

3.5 SMM Level 4 - Managed Security is acknowledged as a desirable property of the organization. The absence of incidents is the result of continuous organizational efforts. The presence of incidents virtually never leads to the maximum impact that could be expected. The results of the organizational efforts are permanent. The Organization Structure does NOT enforce responsibilities partitioning and supervision.

All of the following practices are followed or determined to be irrelevant to the organization’s expectations and environment:

• Plan




HowTo Commitments




• Check Test

• Attacks, Errors and Accidents Emulation • Incidents Emulation • Independent Audits

Monitor • Discovery of new Weaknesses • Incidents and Intrusions Detection

Audit • Act

Incidents and cuasi-Incidents Handling Forensics

• Budget Management Budget Allocation

Página 19 de 24

Return on Security Investment Practices and Security Measures Selection

• People Management Background Check of Personnel Selection of Security Personnel Training on Security Personnel Layoff Security Awareness

3.6 SMM Level 5 - Optimum Security is acknowledged as a desirable property of the organization. The absence of incidents is the result of continuous organizational efforts. The presence of incidents doesn’t lead to the maximum impact that could be expected. The results of the organizational efforts are permanent. The Organization Structure enforces responsibilities partitioning, supervision, separation and rotation. All of the following practices are followed or determined to be irrelevant to the organization’s expectations and environment:

• Plan




HowTo Commitments




• Check Test

• Attacks, Errors and Accidents Emulation • Incidents Emulation

Página 20 de 24

• Independent Audits Monitor

• Discovery of new Weaknesses • Incidents and Intrusions Detection

Audit • Act

Incidents and cuasi-Incidents Handling Forensics

• Budget Management Budget Allocation Return on Security Investment Practices and Security Measures Selection

• People Management Background Check of Personnel Selection of Security Personnel Training on Security Personnel Layoff Security Awareness

Página 21 de 24

4 SMM Handling 4.1 SMM Auditing (What is the current level of maturity?).

(In development)

4.2 SMM Planning (What is the roadmap for going from level x to level y?).

(In development)

4.3 SMM Certification (What professionals are able to perform SMM audits?).

(In development)

5 References • CISSP Domains. • BS7799-2:2002. • CMMI. • SP-800-53. • ISO13335. • ISO9001.

6 Acronyms 6.1 CIA Confidentiality, Integrity, Availability

6.2 ISM Information Security Management

6.3 PKI Public Key Infrastructure

6.4 SMM Security Maturity Model

7 Glossary & Terminology 7.1 Accident An incident for non-human natural causes.

Página 22 de 24

7.2 Asset

7.3 Aspect

7.4 Attack An incident for intentional human cause.

7.5 Catastrophe Any incident that could result in an organization’s demise.

7.6 Critical Critical is a classification of the priority of a service that depends on time. A service is critical in a time span if the interruption of the service for a longer span of time could jeopardize the organization’s existence. Therefore critical services can be ordered depending on the seconds, minutes and hours that the organization can survive without the service being available.

7.7 Environment All the physical, logical and organizational actors external to the organization.

7.8 Error An incident because of a mismatch between the intended and the effective results of an action.

7.9 Evaluation In the SMM context “Evaluate” something means all or some of:

• Identify. • Classify. • Prioritise. • Value qualitatively or quantitatively.

7.10 Expectation

7.11 Incident An disappointment of an organization expectations due to accidents, errors or attacks.

7.12 Interface A mean of input or output of information between a user and an information system.

Página 23 de 24

7.13 Impact The direct and indirect cost of an incident plus the cost of restoring the assets to the pre-incident state.

7.14 Intrusion Any attacker’s gain of information on a target.

7.15 Management To manage something means:

• Define and Achieve Targets. • Optimise the use of Resources.

The main paradigm of total quality management is “plan-do-check”. Information Security Management should follow this paradigm when defining and achieving Targets within the environment of the organization. As any other responsibility, IS Management can be shared with others, or can be taken by a team instead of an individual.

7.16 Message Meaningful data exchanged between services.

7.17 Network A set of channels connecting repositories and interfaces.

7.18 Opportunity The presence of a target, a threat and an occasion for an incident.

7.19 Process A series of tasks that provide a value for an organization.

7.20 Quality The meeting or surpassing of our expectations on something.

7.21 Resource A resource is anything needed to complete a task. Most resources stop being available to any other task when they are being used for a certain one. Some resources are exhausted after the task and can’t be reused. Some fundamental resources are:

• Time. • Money. • People. • Logistics and Infrastructure. • Information and Communications. The main kinds of information can be: Logistic,

Organizational, Procedures, Technical, Normative, Contractual.

Página 24 de 24

7.22 Responsibility An assignment of a task, with power and resources to a competent individual or a team they are accountable for.

7.23 Repository Any permanent or transient storage of data.

7.24 Risk A function of a set of incidents vulnerability and impact, measured in monetary units per year.

7.25 Role A set of Responsibilities. It’s the smallest organizational chart component.

7.26 Security The repeated meeting or surpassing of our expectations on something.

7.27 Security Requirement A testable expression of an expectation.

7.28 Service Any program that provides value for users, via messages exchange with interfaces, or other programs via messages exchange.

7.29 Threat Any potential cause of an incident.

7.30 Vulnerability The likeliness of threat, measured on favourable instances versus possible instances per year.

7.31 Weakness Any threat that arises from faults in services, messages, networks, repositories or interfaces.

7.32 Zone A logical, technical or organizational partition of a whole.

8 Typographical Conventions