Security Assessment Procedure

Introduction

The Information and Systems Security Assessment Procedure of Infocore Solutions has been designed according to the following information technology industry standard security guidelines, techniques and methodologies:

  • ISO/IEC 27001 Information Security Management
  • ISO/IEC 27002 Information technology – Security techniques – Code of practice for information security controls
  • ISACA – CISA Review Manual
  • OWASP Application Security Code of Conduct for Development Organizations
  • OWASP Top Ten Web Application Security Risks
  • SANS Institute CIS Controls
  • NIST SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing
  • NIST Special Publication 800-64 Rev. 2, 2008
  • OECD Guidelines for the Security of Information Systems and Networks
  • RFC 2196, Site Security Handbook
  • Mitre Common Weakness Enumeration

Additionally, our products and services are being developed according to the Infocore Solutions Secure Development Process and our goal is that our partners will enjoy the highest levels of information security by aiding them towards the improvement of their security posture.

Procedure

Phase 0 – Initiation

During this initial phase of the security assessment, a meeting is performed, where the initial security requirements are set. They are either enforced by external sources (i.e. previous attacks, business requirements, standards, regulations, etc) or dictated by internal sources (i.e. standards, process, experience, research).

This is ensured by:

  • Providing a high-level security awareness training
  • Creating technology-specific best-practice security guidance

P0 security-related deliverables:

  • The initial security requirements
  • The education and training of the developers (if required) and the appropriate best-practice guidelines

Phase 1 – Requirements

In the context of this phase, the security requirements are being clarified, assessed and selected.

1. Assess Risk

The risk assessment is performed following the procedure below for each requirement:

  • Examine and document the likely threats
  • Build threat models
    • Collect use cases, data flows, data schemas and possible deployment diagrams
    • Identify Security Objectives (what do we need to protect)
    • Create a system overview (roles, key usage scenarios, technologies, system security mechanisms)
    • Decompose system (data flows, entry points, trust boundaries, exit points)
    • Identify threats (common threats and attacks, threats along use cases, threats along data flows)
    • Identify vulnerabilities
  • Develop attacker profiles defining their type and motivations
    • A methodology of threat assessment is presented at the Appendix I

2. Select Security Controls

After performing the risk assessment, the security-related requirements that must be implemented will be selected. This process comprises:

  • Reviewing the system and specifying security requirements based on functionality
  • Analyzing the compliance and best-practice security guidance documents to derive additional requirements
  • Ensuring that the requirements are specific, measurable and reasonable

3. P1 security-related deliverables

  • Risk assessment
  • Security requirements

Phase 2 – Continuous Monitoring

One of the cornerstones of maintaining a strong security posture is monitoring and reporting. As such, during this phase, the monitoring and reporting procedures will be put in place. Key security activities for this phase include:

  • Plan and conduct vulnerability management
  • Perform continuous monitoring of the system

1. Vulnerability management

  • Define an application security point of contact
  • Create an informal security response team
  • Develop an initial incident response process
  • Implement processes to test and apply critical security fixes

2. Conduct Continuous Monitoring

  • Monitor sources for information about security upgrades and patches for all software in the system
  • Record important software-specific knowledge that affects the deployed application’s security
  • Inform operators/users as appropriate of this understandable/actionable information
  • Provide guidance on handling expected security-related alerts and error conditions

3. P2 security-related deliverables

  • Security Contact & Informal Security Response Team
  • Incident Response Process
  • Security Upgrades & Patches
  • Monitoring Report

Appendix I

Below, an example metric of threat assessment is presented:

  • Risk = Likelihood * Impact [10]
    • The scores range from 0 to 9. Likelihoods and impacts of less than 3 are considered low, 3 to less than 6 medium, 6 and above high

Likelihood ⇒ average of the factors below (more can be added or removed if required or irrelevant – not-applicable)

  • Attacker Skill level
    • How technically skilled does one have to be to take advantage of a possible flaw? Security penetration skills (1), network and programming skills (3), advanced computer user (4), some technical skills (6), no technical skills (9)
  • Attacker Motive
    • Reward for one to find and exploit a flaw? No reward (1), possible reward (4), high reward (9)
  • Attacker Opportunity
    • What resources and opportunities are required for one to find and exploit a vulnerability? Full access or expensive resources (0), special access or resources (4), some access or resources (7), no access or resources (9)
  • Attacker Profile
    • Who can take advantage of a flaw? Developers (2), system administrators (2), intranet users (4), partners (5), authenticated users (6), anonymous users (9)
  • Ease of discovery
    • How easy is it to discover a flaw? Practically impossible (1), difficult (3), easy (7), automated tools available (9)
  • Ease of exploit
    • How easy is to actually exploit a vulnerability? Theoretical (1), difficult (3), easy (5), automated tools available (9)
  • Awareness
    • How well known is this vulnerability? Unknown (1), hidden (4), obvious (6), public knowledge (9)
  • Intrusion detection
    • How likely is an exploit to be detected? Active detection in application (1), logged and reviewed (3), logged without review (8), not logged (9)
      Impact ==> average of the factors below (more can be added or removed if required or irrelevant – not-applicable)
  • Loss of confidentiality
    • How much data could be disclosed and how sensitive would it be? Minimal non-sensitive data (2), minimal critical data (6), extensive non-sensitive data (6), extensive critical data (7), all data (9)
  • Loss of integrity
    • How much data could be corrupted and how damaged would it be? Minimal slightly corrupt data (1), minimal seriously corrupt data (3), extensive slightly corrupt data (5), extensive seriously corrupt data (7), all data totally corrupt (9)
  • Loss of availability
    • How much service could be lost and how vital is it? Minimal secondary services interrupted (1), minimal primary services interrupted (5), extensive secondary services interrupted (5), extensive primary services interrupted (7), all services completely lost (9)
  • Loss of accountability
    • Are the actions traceable to an individual? Fully traceable (1), possibly traceable (7), completely anonymous (9)
  • Financial damage
    • How much financial damage will result from an exploit? Less than the cost to fix the vulnerability (1), minor effect on annual profit (3), significant effect on annual profit (7), bankruptcy (9)
  • Reputation damage
    • Would an exploit result in reputation damage that would harm the business? Minimal damage (1), Loss of major accounts (4), loss of goodwill (5), brand damage (9)
  • Non-compliance
    • How much exposure does non-compliance introduce? Minor violation (2), clear violation (5), high profile violation (7)
  • Privacy violation
    • How much personally identifiable information could be disclosed? One individual (3), hundreds of people (5), thousands of people (7), millions of people (9)