Read More

ISO IEC 12207 2008 Systems and Software Life Cycle Processes Overview

                                                                                 Download the Complete Article

In our previous blogs we have been discussing about the available frameworks and standards set by different organization for software Development processes. Another industry standard related with Secure SDLC process and practices is from ISO (International Organization for Standardization).

Read: 
Summarizing OpenSAMM Requirements 
BSIMM7 Software Security Framework A Quick Walk through 
NIST SP 800 64 Secure SDLC Consideration High Level Summary

The International Organization for Standardization (ISO) along with IEC (The International Electro Technical Commission) provides an international standard for software Lifecycle Processes as ISO/IEC 12007. This International Standard sets a common framework comprises of Process activities and tasks to be utilized by all software practitioners to develop and manage software products or services during the different phase of development lifecycle.

ISO 12007 provides the Lifecycle Process Reference Model, which can act as the adoptable reference model by an organization based on Business needs and Application domain. This assist process assessors to determine capability of the organization’s implemented process and to provide source material for further improvement in same.

This Standard Categories itself in 2 subdivision of processes

1. System Lifecycle Processes dealing with Software System

  

2. Software Specific Processes dealing with software product or services related processes.

  


Let’s walk through these processes in brief

1. System Context Processes

1.1 Agreement Processes

It describes a set of Agreement processes which happens from the start of the software till its retirement. It involves several key parties in the process like Acquisition, supply, development, operation and maintenance. Each process is defined in terms of its activities and tasks.

1.1.1 Acquisition Process 
The purpose of the Acquisition Process is to ‘obtain’ product/service requirements that satisfies need of the acquirer (Client). It begins with identifying the customers need and ends with the acceptance of the Product/Service needed by the acquirer. And continues with tasks like issuance of proposal, selecting a supplier, and defining the management for the acquisition process.

This process results in clearly defined agreement for the acquirers requirement and expectations, selection of the product/service that satisfies the acquirers need, defining the cost, schedule to meet the need, and any other requirement to be agreed between the acquirer and supplier.

This Process consists of certain activities and task that can be seen below in the chart.Acquisition_Process

1.1.2 Supply Process 
This life cycle process contains the activities and tasks to provide the product/service to the acquirer that has been agreed upon in the requirements. This process is initiated by entering into the contract with the acquirer with the agreed requirements to provide a software service. The process then continues with the identification of the procedure and resources to manage the services. Then the product is installed depending upon the agreed requirements.

This Process consists of certain activities and task that can be seen below in the chart.

1.2 Organizational Project-Enabling Processes

Organizational Project-Enabling Processes consists of different processes to initiate the system procedure.

1.2.1 Life Cycle Model Management Process 
This process defines the policies, procedures, Lifecycle model and processes that can be adapted and applied using effective measures and tools, with respect to the scope of this international standard.

The successful implementation of this model ensures a well-defined policies and procedure, and accountability for lifecycle management. This process includes activities like:

a.Process Establishment, where suite of organizational processes for all software life cycle processes and models according to business activities are established, documented and published
b. Process Assessment, where procedure to assess/review records and activities are developed, documented and applied
c. Process Improvement, ensures required activities related with suggested improvements are collected, evaluated and analyzed for further process changes

1.2.2 Infrastructure Management Process 
This process defines the activities, tools and facilities needed to acquire, establish and maintain an enabling infrastructure services to the project throughout the lifecycle.

1.2.3 Project Portfolio Management Process: 
This purpose of this process is to initiate and sustain the necessary projects to meet the organization's objective. Under this process, investment authorities, resources and budget are selected, and continued monitoring is done to confirm they justify continue investment or not.

1.2.4 Human Resource Management Process: 
This process helps in identifying the skilled resources to perform the activities of the life cycle to meet the organization's, project and customer’s objective. It also defined the ways to develop, maintain and enhance their skills and competencies.

1.2.5 Quality Management Process 
This process defines the framework for objectively assuring the compliance and quality objectives of product/services with their requirements and to monitor the customer satisfaction with those quality objectives. Corrective Actions are taken if these are not met.

1.3 Project Processes

The Standards is written for general, large or complex projects. The standard is valid to be applied in projects of any size. It consists of several processes to be applied.

1.3.1 Project Planning Process 
Primary purpose of Project Planning process is to produce and communicate effective and workable project plans, determining scope of project Management and Technical activities

1.3.2 Project Assessment and Control Process 
This process helps in assessing the project work as per the plan and scheduling. It also determines that the project is working under estimated budget and satisfies the project objectives.

1.3.3 Decision Management Process
This process determines the most valuable and accurate action for the project and their alternatives by taking desirable decisions for the project.

1.3.4 Risk Management Process
The scope of this process is to define strategies to identify, monitor and mitigate the risks that occurs during the life cycle process. Some of the important activities includes

a. Risk Management Planning, which provides policies and guidelines under which Risk Management needs to be performed. It also defines roles and responsibilities of involved parties along with evaluation metrics
b. Risk Profile Management, provides context of Risk Management Process including threshold conditions under which Risk may be accepted
c. Risk Analysis, describes Categories, probability of occurrence and consequences of each risk identified.
d. Risk Treatment, contains recommended measures, actions and alternatives to different stakeholders.
e. Risk Monitoring activity provides measures to evaluate effectiveness of Risk treatment along with process to monitor for new risk and sources throughout its lifecycle.
f. Risk Management Process Evaluation, contains activities related with Information collection for purpose of process improvement and generating Case Studies accordingly. It also defines periodic review outcome for identifying systematic project and organizational risks.

1.3.5 Configuration Management Process
This process is employed to identify, define, and baseline software items in a system, to control changes and releases of the items, to record and report the status of the items and modification requests; handling and delivery of the items.

1.3.6 Information Management Process 
The scope of this process is to manage and provide the valid, complete and confidential information to relevant parties. It also make sure that the information is transformed and disposed-off when needed.

1.3.7 Measurement Process
The purpose of this process is to identify the information needs of the project, to identify appropriate set of measures, to collect and analyses the data, and to demonstrate the quality of the product.

1.4 Technical Processes

This consists of different technical procedure that defines the technical aspect of the project.

1.4.1 Stakeholder Requirements Definition Process 
The scope of this purpose is to identify the stakeholders and their needs and requirements and validate the operational serves to confirm that it meets those needs. Project should implement following activities and task according to Business requirements:

a. Stakeholder Identification, process is about identifying stakeholders who are interested in the system throughout its life cycle
b. Requirements identification, providing details of stakeholder requirements, also including constrain/unavoidable conditions and consequences of existing agreements and (management & technical) decisions. 
c. Requirements Evaluation, to analyze complete set of elicited requirements
d. Requirements Agreement, to provide detailed requirement and expectation set
e. Requirement Recording, in form of suitable requirements management through lifecycle and beyond to provide traceability to source of stakeholders need.

1.4.2 System Requirements Analysis Process 
This process transforms the stakeholder’s requirement into technical requirements that will be used to design the system. The selected techniques are performed to finalize the solution, cost and schedule is also determined and selected requirements are communicated to respective parties.

1.4.3 System Architectural Design Process
The purpose is to identify the system elements that meets the defined requirements. It includes establishing top-level architecture of the system with allocated all system requirements, followed by a systematic evaluation process for proper traceability, consistency, appropriateness of standards and feasibility of operation and maintenance.

1.4.4 Implementation Process
This process helps in defining the specific system element.

1.4.5 System Integration Process
This process helps in integrating the specified system elements in project to produce a complete system defined as per defined requirements and customer expectations.

1.4.6 System Qualification Testing Process
This process is about testing the system to ensure the implementation of each requirement for compliance and assure the readiness of the system for delivery.

1.4.7 Software Installation Process
This process defines the installation of the software product and assure the readiness of the product to be used in the target environment.

1.4.8 Software Acceptance Support Process
This process helps to derive the acquirer acceptance of the product by certain tests and reviews and if any problems are detected during acceptance that needs to be communicated to the respective party.

1.4.9 Software Operation Process
The purpose of this process is to test and operate the software product in its intended environment and provide consultation and assistance to the customer. 

Primary activities included in this process are:

a. Preparation for operation, where operator develop well documented plan and set operational procedures for performing activities and task of this process.
b. Operation Activation and Check-Out, this includes performing acceptable operational testing before release of product in production environment.
c. Operational use, includes activities related with setting up required environment as defined under user documentation
d. Customer support, should be established to provide assistance and consultation to users as requested.
e. Operation Problem Resolution, includes process related with forwarding identified problems to related stakeholder and setting-up Software Problem Resolution process for same.

1.4.10 Software Maintenance Process
This process helps in modifying the system product and provide cost effective support to the software product as and when required.

Primary activities to be implemented by Maintainer should include:

a. Process Implementation, for Software Maintenance with documented executable plans and procedures.
b. Problem and Modification Analysis, process to analyze problem report or modification request for its impact on organization and related systems
c. Modification Implementation, process to determine which system component needs modification. Further Technical processes to be considered for modification implementation.
d. Maintenance Review/Acceptance, includes reviews and required approval for satisfactory completion of modification request
e. Migration, process and activities to be considered if environmental changes are considered. Plan needs to be developed, documented and systematically executed.

1.4.11 Software Disposal Process
This is the end of the process, describing the effective handling over of the product to the customer and disposing off or storing of any software elements in lieu of compliance, leaving the environment in an acceptable condition.

2. Software Specific Processes

2.1 Software Implementation Processes

This consists of different processes to be used on the produced software.

2.1.1 Software Implementation Processes
This process helps in producing the system element also known as “system item” to be implemented as a software product or services that satisfies the architectural design requirements.

2.1.2 Software Requirements Analysis Process
This process defines the requirements to be allocated to the system which is further tested to analyses their impact on the system.

2.1.3 Software Architectural Design Process
This process provides a design for the software that will implement the specified requirements.

2.1.4 Software Detailed Design Process
During this process a detailed design of each software component is developed which can be available for testing and coding.

2.1.5 Software Construction Process
Here all software units are verified against their requirements and constructed as per the defined design.

2.1.6 Software Integration Process
This process defines the integration of the software unit and software components to produce software items, consistent with software design demonstrating functional and non-functional software requirements on complete operational platform. 

2.1.7 Software Qualification Testing Process
This process helps in identifying that the software product meets the requirements established in sync with the compliance.

2.2 Software Support Processes

These processes lists the number of processes to support the produced software

2.2.1 Software Documentation Management Process
This demonstrate the process of identifying the documentation of the produced software, develop and maintain the recorded information produced during the process.

2.2.2 Software Configuration Management Process
This process helps in maintaining the integrity of the software items, storing, handling and delivering them to the concerned parties. Primary activities implemented by the project as a part of this process are:

a. Process implementation, includes Software Configuration management plan describing related activities, procedures and schedule along with roles and responsibilities of stakeholders performing these activities
b. Configuration Identification, scheme for proper identification of Software items requiring version control and related management activities
c. Configuration Control, provides process to identify, record and evaluate change request.
d. Configuration Status Accounting, includes management records and status reports showcasing status and history of controlled Software items.
e. Configuration evaluation, to ensure functional completeness of Software items against requirements.
f. Release Management and Delivery related activities including required documentation of same.

2.2.3 Software Quality Assurance Process
During this process quality assurance check is done on the product and assurance is provided that the product meets the pre-defined plans and requirements.

Primary activities defined as a part of process are:

a. Process Implementation, includes establishment of Quality assurance process suited to the project and in compliance with established requirements and plans
b. Product assurance, process ensuring all plans as per contract are documented and delivered. It also assures acceptable delivery of Software Product to acquirer (client).
c. Process Assurance, process to ensure all software lifecycle processes are as per contract and plans.
d. Assurance of Quality Systems, includes activities accordance to ISO 9001 clauses.


2.2.4 Software Verification Process
The purpose of this process is to verify the software work products or services and identify any defects. This explains the product meet the requirement and then it is made available to the customer. Primary activities includes Verification of all Requirements, Design, Code, integration needs and Documentation. 

2.2.5 Software Validation Process
Under this process all work products are validated for the specific intended use according to the requirements.

2.2.6 Software Review Process
The scope of this process is to review the management and technical progress against the objective throughout the life of the product. Problems during review are identified and recorded as well. Primary activities of this process includes

a. Process Implementation, process and setting resource requirements for periodic reviews. It also includes process to document and distribute result to required stakeholders.
b. Project management reviews, to evaluate project status as per applicable project plans, schedules, standards and guidelines.
c. Technical Reviews, to ensure product or service under consideration are complete, comply with Standards and specifications, Properly implemented suggested changes (as per Change Management plan) and  adhere with applicable schedules.

2.2.7 Software Audit Process
The product then goes through the audit process to determine that the software work products meets the compliance, plans and agreement.

2.2.8 Software Problem Resolution Process
This process demonstrate that all the problems are identified, analyzed and resolutions are implemented.

2.3 Software Reuse Processes

These consists of three processes

2.3.1 Domain Engineering Process
This process helps to develop and maintain domain model, domain architecture, build relationship with other domains, and assets belonging to domain are identified.

Primary activities includes

a. Process Implementation, involving creation and execution of Domain engineering Plan. 
b. Domain Analysis, includes activities like defining Domain Boundaries, building Domain Models, constructing Definitions and Terminologies and conducting Reviews. Domain Models and analysis reports should be submitted to Asset Manager.
c. Domain Design, includes creation and documentation of Domain Architecture along with selected Asset evaluation.
d. Asset Provision, should include activities like documentation and Classification of Assets. Asset Evaluation as per Organization’s acceptance and certification procedures.
e. Asset Maintenance, includes analysis of Asset modification request and choosing implementation options according to impact, Business requirements and Organization Policies.

2.3.2 Reuse Asset Management Process
The purpose of the Reuse Asset Management Process is to manage the life of reusable assets from conception to retirement. Primary activities includes

a. Process Implementation, like Asset Management Plan to define resources and required procedures for managing assets.
b. Asset Storage and Retrieval Definition
c. Asset Management and Control, related task based on asset acceptance and certification criteria. If asset is accepted, it can be made available for reuse through Asset storage and Retrieval mechanism.

2.3.3 Reuse Program Management Process
This process defined the reuse strategy for potential reuse opportunities, and manage and control organization's reuse program.

Primary activities in this process includes:

a. Initiation, includes task like implementation of Reuse Program as per organization’s reuse strategy and scope.
b. Domain identification, includes identification and documentation of domains which require and investigate reuse opportunities. Further these identified domains are evaluated, reviewed and scoped for future usage.
c. Reuse Assessment, process to assess organization’s reuse capability, domain reuse potential, recommendations and improvement plans
d. Planning, involves activities related with proper creation, documentation and maintenance of Reuse program implementation Plan. This plan should be reviewed and evaluated for required implementation feasibility as per organization’s reuse strategy
e. Execution and Control, includes activities required for reuse program implementation, progress monitoring and re-structuring requirements
f. Review and Evaluation, process for periodic assessment to get reuse program align with organization’s strategy. It also involves, required changes to reuse program and improvement in same accordingly. 


The ISO/IEC 12207 is the first International Standard that provides a complete set of processes for acquiring and supplying software products and services. These processes helps in improvement of software throughout its lifecycle by evolving modern software methods, tools and techniques and engineering environment. This International standard will help organizations to indulge themselves in acquiring the proper development process and develop a product which will be accepted internationally.

At Hack2Secure, We work closely with organizations to improve their Software Development Lifecycle processes and assist them in adopting and implementing role of Security in these processes. 

Read More

Summarizing Open Software Assurance Maturity Model OpenSAMM Requirements

Download the Complete Article

Earlier, Information Security was all about protecting your network from malicious activities. But today, with the evolution of technologies and extended usage of devices and applications, information security has become a Business concern for any organisation. We now have to re-work on our development processes, methodologies to improve maturity of Application Security and adopt related Practices.

Many organisations have come up with their own frameworks to help this initiative keeping their Business requirements in view, however these frameworks lack flexibility and might be too complex for some organizations to adopt. Industry needs a model which is simple, defined and measurable. One such model is The Open Software Assurance Maturity Model (OpenSAMM), which is viable and can define building blocks for an assurance program.

About OpenSAMM

The Software Assurance Maturity Model (SAMM) developed by OWASP in 2009 is an open (free & vendor neutral)  framework assisting organizations in understanding, formulating and implementing Software Security strategy, which can be customized completely based on risk faced by the organization. 

Benefits:

  • Analyse existing Software Security Maturity state of an organization according to the followed practices and assurance programs
  • Build a balanced Software Security assurance program in a systematic and well-defined iterations
  • Demonstrate improvements in Security Assurance program and Software Security maturity
  • Define measurable Security activities across an organization.

 

Understanding the Model

At highest level, OpenSAMM defines 4 critical Business functional blocks, each providing 3 Security practices. So, in-total of 12 Security Practices, each practice is measured at 3 Maturity Levels, also called as Objectives.

To Summarize, we have,

4 Critical Business Functions (B.F.)

4 B.F. x 3 Security Practice = 12 Security Practices (S.P.)

12 S.P. x 3 Maturity Levels = 36 Objectives

Let’s, walk through these Business Functions, Practices and required objectives in brief:

A. Governance

Governance is all about the way Organization Manages Software Development Activities. It provides relations between effective Business Processes and Development groups, by providing effective measurable process and engagement rules.

1. Strategy & Metrics (SM)

This practice involves building Strategy to collect metrics defining organization’s Security posture. It assists in establishing a framework within organization for a Software Security Assurance program.

Objectives

Strategy & Metrics Practice has 3 related Objectives, focussing on Establishment of Strategic Roadmap, which assist in measuring Data and other Software Asset values based on Business Risk. It also help is assessment of possible Security expenditure required to maintain Security posture.

2. Policy & Compliance (PC)

This practice primarily focuses on external legal and regulatory requirements and driving internal Security Standards to ensure required business purpose and compliances are met.

Objectives

Policy and Compliance Business Practice has 3 related objectives, focussing on understanding of relevant governance and compliance requirements to the organization. This understanding assists in establishing Security Baseline (Policies and Standards) and related practices. It also assists establishing required compliance/quality gates for projects. Overall objective is to understand pre-project Risk and establish measures to manage them.

3. Education & Guidance (EG)

This practice is all about ensuring Educating and Guiding workforce involved in Software Lifecycle with required knowledge and resources to design develop and deploy secure software. This practice assist teams in proactively identify and mitigate related Security Risk in their domain.

Objectives

Primary objective of Education and Guidance practice is to educate all personnel in Software life-cycle on Security Requirements and provide guidance according to their Role. Like, Developers should be trained on Secure Programming and Deployment practices. It also includes providing mandatory awareness Security Training and Certification programs.

B. Construction

Construction concerns the processes and activities related with Business Goals and Development projects. Overall it defines process of Building an Application, which includes activities related with Product management, Requirement gathering, High-level Architecture specification, detailed Design and implementation analysis.

1. Threat Assessment (TA)

This practice involves identification of project level Functional Threats and Risk to Software. Processes like Threat Modeling assist in such analysis.

Objectives

Primary objective of this Security Activity is to identify and understand impact of possible Threats to an organization and project, assisting organization to granularly define and implement Security Controls. This includes threats against both internal and third-party software.

2. Security Requirements (SR)

This practice is all about building proactive practices, providing expected Software security behaviour. As a part of project initiation, security requirements along with functional expectations are collected for high-level business purpose.

Objectives

Mandated across projects, objective of this practice is to ensure Security explicitly during Software requirement gathering process. This increase granularity of Security controls against business logics and known risk including from 3rd party dependencies and SLAs.

3. Secure Architecture (SA)

This can also be taken as a pro-active Security practice to ensure Security is ensured by default in Software Design itself.

Objectives

Primary objective of this practice is to consider security in Software design and related processes itself by using known secure services and design principles. Establishment of formal reference security design architectures and patterns are done as a part of that 

C. Verification

As name suggest, it is related with verification and testing of Software. It focuses on processes and activities related to how organization review and analyse (test) produced entities throughout Software development.

1. Design Review (DR)

This practice is focussed on assessment of Software design and architecture for security concerns. It involves detailed data-level design inspections and enforcement of Baseline expectations at design level.

Objectives

Identification of Software Attack Surface, analysis against known Security Requirements, Development of Data flow diagrams and inspection of complete Security mechanism are few objectives of this process. It also includes adding requirements in Release Gates related with design review, which needs to be applied across projects.

2. Code Review (CR)

This practice focuses on software source code inspection for Security vulnerabilities. It involves integration of Code review practices in development process and setting measurable expectations for same.

Objectives

Objectives include creation of review checklist from known security requirements followed by both Automated and Manual code analysis process. It also includes adding requirements in Release Gates related with secure code review, which needs to be applied across projects.

3. Security Testing (ST)

This practice focuses on software inspection in runtime environment for Security concerns. It also involves adding Security Functional aspects in automated environment. Security testing results should play major role in project release acceptance criteria.

Objectives

Primary objective of this Security practices is to at least establish a process of performing basic security test based on implementation and Software requirements and then further effectively automate the complete process. Security testing phase should be part of Release Gate criteria.

D. Deployment

Deployment business requirement talks about processes and activities related with Software release procedures. This also includes how products are shipped to end users, deployment of same and expected operations in runtime environment.

1. Vulnerability Management (VM)

Vulnerability Management practices defines the required processes for handling Vulnerabilities and Operational incidents. It talks about methods of collecting information from reports and analysing root case for the concern. 

Objectives

This includes building of High Level Plan for effective Vulnerability or Incident Management, which may involve creation of Security Response Team and establishment of Incident Response process for same. Along with these, a process should be established to effectively conduct root-cause analysis and collection of incident metrics.

2. Environment Hardening (EH)

This practice assists in hardening of Security posture in the surrounding environment of Deployed Software.

Objectives

This includes maintaining of operational environment specification along with identification and installation of Security upgrades and patches. Establishment of Patch Management process is a part of Environment Hardening practices. Along with these, consideration should be taken on deployment of required operation protection tools and expansion of audit program to analyse environment configuration.

3. Operational Enablement (OE)

This Security practice primarily focuses on communicating Secure Deployment and other critical information to end-users. Providing details on Security configuration, features and Best Practices are part of same.

Objectives

Primary objective here is to document procedures especially alerts and critical security information in form of Operational and Security Guides. This also involves creation of pre-release change management procedures. Effective validation criteria should be established like Code Signing etc. Audit program should also be expanded for this prospect.

 

Building Assurance Program

The main purpose of using SAMM is to build a software assurance model for an organisation. This process begins with the Security assessment using existing model in the organisation. After the assessment, OpenSAMM proposes several roadmaps templates to choose from. Organizations can further customize their roadmap based on these templates, which explains which section of Security practice needs improvement and try to achieve the required level.

 

The Open SAMM Model is quick and easy to deploy and will help organisations to improve their Software Security state by building Assurance Program, according to organisation structure and understanding. It allows them to do self-assessment with some guidance to gain valuable insights on their Software assurance matters and help Demonstrate concrete improvements to their security assurance program. Their future plan also includes mapping them with existing standards like ISO, PCI and more.

Hack2Secure can assist organizations in analysis and adoption of OpenSAMM model for Secure SDLC process implementation. Our Training, Certification, Consultation, Testing and Assessment services can assist organizations across the OpenSAMM model requirements.

Download the Complete Article

Read More

BSIMM7 Software Security Framework A Quick Walk through

                                                                         Download The Complete Article

With the continuous increase in data breach, organisations have started taking Security seriously and have also introduced Secure Software Development (SDLC) programs in their systems. But the dilemma is that they don’t know where to start from. Even though they are investing into security activities, measuring the impact of these security services are often overlooked. Which results in over investment on low-impact activities. There are many standards and frameworks developed for such organisations to measure their state of Software security. One such Framework is called The Building Security in Maturity Model (BSIMM). 

What is BSIMM?
BSIMM is a software security measurement framework established to help organisations compare their software security to other organisations initiatives and find out where they stand. 

“The Building Security In Maturity Model is a study of existing software security initiatives. By quantifying the practices of many different organizations, we can describe the common ground shared by many as well as the variation that makes each unique”.
[Source: BSIMM]

The model is based on the study done on organisations across the industries like financial service sectors, Healthcare sectors, Software sectors, cloud providers and more.

How does BSIMM work?

The model is based on observational science around software security. Over the years of research and findings, it provides a common measuring stick with using 113 activities for organizations. These activities are broken into 12 practices organized into 4 Domains viz. Governance, Intelligence, SSDL Touchpoints and Deployment. BSIMM’s Software Security Framework (SSF) and activity description provides a common mechanism to explain elements of Software security initiatives, thus enabling organizations to uniformly compare their maturity model accordingly. BSIMM7 is the 7th major version of BSIMM model.

Advantages of adopting BSIMM7 framework:

  • Enables organizations to start a Software Security Initiative (SSI)
  • Provide standard measuring criteria  to measure and comparing SSI within domain or Industry
  • Helps organisations to learn from other’s mistakes. So that they don’t repeat the same. It helps the members of The BSIMM community by bringing together people from companies who've measured and they can compare notes and realize that often they have the same problems. 
  • It will help them to plan, execute and measure initiate of their own without having on board any third party for the same. The analysis consists of around 100 big companies like Microsoft, EMC, Google etc, which can help you leverage the years of experience captured in the model and help you improve your own software security initiative. 
  • It gives you the clarity on what is “the right thing to do”.
  • This model will helps industries and business units, measure the current state of their software security initiative, identify gaps, prioritize change, by applying scientific principles and determine how and where to apply resources for immediate improvement by comparing it with other existing Security Software initiative organisations. 
  • It helps in Cost reduction through standard, repeatable processes.


BSIMM Framework
BSIMM7 Framework is the study 113 different activities of 4 domains consisting 12 Practices: 
Ref: https://www.bsimm.com/framework/

Bsimm maturity model

A. Domain: Governance
These are practices assisting companies to organise, manage and measure a Software Security Initiatives (SII). 

1. Strategy & Metrics (SM): 

This practice ensures Security Process planning and publication assisting in defining Software Security Goals and required measurement metrics. Identify Quality Gates along with definition on roles and responsibilities. It also talks about Awareness related education programs especially for Management/Executives to ensure well-informed decision making

2. Compliance & Policy (CP): 

As name suggest, Compliance and Policy practice has focus on regulatory or compliance drivers such as PCI DSS and HIPPA. It consist of activities related with PII obligation identification, defining Security Policy and processes to fulfil such requirements like defining SLA, Contracts, audit scope etc.  

3. Training (T): 

Training is required to have basic security knowledge for all level of participants in SSDLC. Awareness Training should be mandatory for all along with identification training requirement based on individual Role and Responsibility. 

[Also Read: Equip Your Workforce To Counter Application Security Resource Gap & Industry need Resources with Secure SDLC skills ]

B. Domain: Intelligence

These are practices results in collection and identification of corporate intelligence related with SSI. Pro-active Security Guidance along with processes like Threat Modeling define different activities.

4. Attack Models (AM): 

In this practise developer think like an attacker and create knowledge of technology specific attack patterns. These knowledge will then guide decisions about code and controls. Data Classification, collecting information on technology-specific attack patterns, building possible attack list and related case studies etc are some of the major activities as part of defining Attack Models.

[Also Read: Secure the Design for Low Cost Security Control Implementation ]

5. Security Features & Design (SFD): 

SFD practice provides guidance of building, reviewing and publication of proactive security features, building or providing pointers to secure-by-design frameworks along with mature design patterns for major security controls. 

6. Standards & Requirements (SR): 

This practice explains the standard explicit security requirements for the organisations. It assist in both building recommendation and tracking of standard Security Controls to be used aligned with Industry standards. Creation of review board, SLA checkpoints and policies to handle open source risk are part of same.

[Also Read: Security Requirement CheckList Considerations in Application Development ]

C. Domain: SSDL Touchpoints

This domain is the most familiar of the four. It talks about essential security best practices required in Software development phases (SDLC). 

[Also Read: Integrating Security across SDLC Phases]

7. Architecture Analysis (AA): 

Primary goal of this practice is to build the quality control, by performing security feature and design review process for high-risk applications.  

[Also Read: Secure the Design for Low Cost Security Control Implementation & Threat Modeling Process for Secure Design Implementation ]

8. Code Review (CR): 

As name suggest, this practices includes activities related with Secure Code implementation and review process. Defining different Roles involved in Code review process, Standards to follow in Coding along with process for Defect management is part of same. It also provides track for both manual and automated code review process. 

9. Security Testing (ST): 

This practice deals with activities related different Security Testing methods like Black-box, Fuzzing, Automation, Risk driven White Box Analysis etc. It deals with vulnerabilities in application construction. 

D. Domain: Deployment

This domain includes practices that deals with network security and software maintenance requirements. Software configuration, maintenance and other environment issues and their impact are detailed in this domain.

10. Penetration Testing (PT): 

This practice involves the activities related with vulnerability discovery and correction of security defects, on to the software that has moved to deployment. This needs to be done adhering to standards and reuse of approved security features. Handling external Penetration Testing process and defining scope for same is part of such activities.

11. Software Environment (SE)

This practice includes activities related with Secure Software Deployment and maintenance. Usage of Code protection mechanism, publication of Installation and Secure deployment practice/guides, Configuration documentation etc are part of such activities. It also talks about mechanism related with application behaviour monitoring and diagnostics. 

12. Configuration Management & Vulnerability Management (CMVM): 
The goal of this practice is track activities related with patching, version control and change management. It also deals with building Incident Handling plans and simulate responses in software crisis.

BSIMM standards are highly accepted by organisations across the industries and it is also helping them to compare their software security initiations with industry peers. This is helping them to increase their business units, and drive their budgeting. According to number of Security reports, the computer security industry as a whole is growing fast at a rate of about 8.9% per year, generating between $20 and $40 billion in revenue annually. Currently, Software Security accounts for 10% in that growth and is growing at twice the rate per year.
 
Hack2Secure  assist organization is adoption of BSIMM framework along with evaluation and implementation of Security controls across Secure SDLC phases.

Download The Complete Article

Read More

NIST SP 800 64 Secure SDLC Consideration High Level Summary

Download the Complete Article

Secure SDLC has been an influencing factor when it comes to Application development. Looking at the number of increasing threats and attacks across the industries, almost all the organisations are now focusing on integrating Security in their Application development process to avoid any such instances in future. Security should be incorporated at the early stage of development cycle rather than doing it later. However this needs to be done keeping in mind the guidelines and frameworks set by The Information Technology Laboratory of the National Institute of Standards and Technology (NIST) and other organisation to add cost effective security step by step in all the phases of SDLC.

The guide presented by NIST SP 800-64 rev2 complements the Risk Management Framework by having a comprehensive approach of managing risk and appropriate level of security based on the levels of risk. It helps in providing the way of  integrating security functionality and assurance into the SDLC.

[Also See Blog: Integrating Security Across SDLC phases]

To be most effective, information security must be integrated into the SDLC from system inception.

                                                                     Ref: NIST SP 800-64 rev2

Early integration of security in the SDLC ensures max. ROI in Security programs.

How?

  • Early we identify possible Security concerns, lower the Security Control Implementation and Vulnerability mitigation Cost
  • Awareness of potential engineering challenges that one may encounter in future.
  • Challenges and Effective Security control implementation
  • Identification of shared security services and reuse of security strategies and tools, reduces overall Development cost
  • Ensures Security is build-in, improving overall Security posture of a product
  • Informed executive decision making through comprehensive risk management in a timely manner.

 

NIST SP 800-64 rev2 guide focuses on Information Security components of SDLC. First describing Key Security Roles and Responsibilities in SDLC and thereafter detecting relation between Information Security and SDLC.

Key Roles and Responsibility in SDLC:

During the whole SDLC process many Participants are involved to perform different activities in the different phases. Some of the key roles and their responsibilities is explained below:

Authorizing Official (AO): Executive responsible for acquiring/operating of an information system at an acceptable level of risk.

Chief Information Officer (CIO): Responsible for Planning, Budgeting, investment, Performance and acquisitions.

Configuration Management (CM) Manager: Responsible streamlining Change Management Processes and controls changes which may affect Security Posture of the System

Information System Security Officer (ISSO): Responsible for ensuring the security of the system throughout the Lifecycle.

Privacy Officer: Responsible for ensuring the privacy of procured services or system.

Program Manager: Manages the functional system requirement during SDLC and responsible all business and program handling during Lifecycle process.

QA/Test Director: Responsible for reviewing system specifications and determines test needs, and works with Program Managers to plan activities leading up to field test activities. Also responsible for system test, evaluation and execution of test plan as mentioned in specification.

Chief Information Security Officer (CISO): responsible for imposing policies of integrating security into SDLC.

Software Developer: Responsible for Secure Coding, implement controls and other CM issues.

System Architect: Responsible for designing and maintaining the system architecture. Also ensures quality of specification, documentation etc.

System Owner: The system owner is responsible for the procurement, development, integration, modification, operation, and maintenance of an information system.

 

Incorporating Security into SDLC

In NIST guide, SDLC process has been described as a 5-step Process. Each step is assigned set of security tasks.

Theses phases are

  • Initiation phase
  • Development/Acquisition Phase
  • Implementation/Assessment Phase
  • Operations/Maintenance Phase
  • Disposal Phase

Let’s discuss the standards set by NIST for each one of the phases:

Initiation Phase:

During this phase the enterprise establishes the project goals and system requirements and document it. It will help in early planning and risk assessment which will help developers to define the threat environment in which system will operate. NIST standards require organisation to categorise the impact of their security breach, i.e., loss of Confidentiality, Integrity or Availability, in 3 levels, Low, Moderate or High and to select appropriate security control. Security categorization standards assist organizations in making the appropriate selection of security controls for their information systems.

Major Security Activities in Initiation Phase:

  • Initiate Security Planning
    • Identify Key Security Roles & Stakeholder Security Integration Awareness
    • Identify Sources of Security Requirements
    • Outline Key Security Milestones
    • Security Reporting Metrics
  • Categorize Information System
    • Based on Potential Business Impact, Risk analysis
    • Assist in making appropriate Selection of Security controls
  • Business Impact Analysis
  • Privacy impact Analysis
  • Ensure use of Secure Information System Development Processes
  • Plan for required Security Training

[Also See Blog: Security Requirement CheckList Considerations in Application Development]

Development/Acquisition Phase:

At this stage, the system is designed, purchased, programmed, developed, or otherwise constructed.  

Major Security Activities in Development/Acquisition Phase

  • Initial Risk assessment
    • To evaluate System’s design and Security Requirements
    • Evaluate Security Controls effectiveness
  • Select and Document Security Controls
  • Design Security Architecture
  • Security Control implementation in System Design
  • Develop Security Documentation
    • Configuration Management Plan
    • Contingency Plan, Incident Response Plan
    • Continuous Monitoring Plan... etc
  • Security Assurance analysis
  • Different hardware, software etc Cost consideration
  • Initial  documents for System Certification and Accreditation

[Also See Blog: Secure the Design for Low Cost Security Control Implementation]

Implementation/Assessment Phase:

At this stage the developers review the system design by installing the system security features and tests its functionality before placing the system into operation, as described in the specifications. Security controls are integrated at the operational site through established techniques and procedures. The results are supposed to be documented to be used in later phases.

Major Security Activities in Implementation/Assessment Phase

  • Create Detailed Plan for Certification & Accreditation (C&A)
  • Integrate Security into Established Environments or Systems
    • Integration and Acceptance Testing
    • Enabling Security control settings
  • Assess System Security
    • Validate system functional and security requirements
    • Testing of Security Controls and their resiliency
  • Security Accreditation: Authorize Information System to process, store or transmit information

Operations/Maintenance Phase

At this phase, system is operating and continuously monitored to ensure the pre-established requirements are incorporated, and hardware, software components are added or replaced. Configuration Management (CM) and control activities is required to establish an upgrade  of hardware, software, and firmware components for the information system and to document any actual change in the system, which is essential to ensure continuous monitoring and reporting the status of the comprehensive information security program.

Major Security Activities in Operations/Maintenance Phase

  • Review Operational Readiness to handle unplanned modifications to system
  • Perform Configuration Management and Control activities to ensure consideration of potential security impacts due to specific changes in the system
  • Conduct Continuous Monitoring to ensure effectiveness of security controls over time

Disposition

At this stage the contract closeout and the disposal of the systems is provided. An orderly termination of the system is done by preserving all the vital information of the system according to the record management regulations so that it can be reactivated in future if needed. It also ensures that the data is deleted, erased or written over as necessary, Hardware and software should be archived, dispose of as directed by the authority.

Major Security Activities in Operations/Maintenance Phase

  • Build and Execute a Disposal/Transition Plan
  • Ensuring Information Preservation (Backup) and Retrieval methods
    • Legal requirements related with Record retention, when disposing systems
  • Media sanitization policy to prevent unauthorized information disclosure
  • Hardware and Software disposal policy
  • System closure or disassembling policy

 

Additional areas for Security Considerations

The developers should use NIST SP 800-64 as a reference document in conjunction with other NIST publications throughout the development of the system. “Building Security In” is a Security management technique that implements specific security considerations during SDLC phases. Let’s walk through different security oriented considerations for Service-based or cross-IT platform initiatives.

Supply Chain and Software Assurance

This process require to showcase best practices and methodologies to promote security and integrity in the hardware and software. It should target three goals. Trustworthiness, Predictable Execution and Conformance. Towards these goals, acquisition managers and information security managers should factor in risks posed by the supply chain as part of their risk mitigation efforts.

Service-Oriented Architecture (SOA)

It is an architectural design, where existing or new functionalities are packed as services. These services communicate with each other by passing data from one service to another. NIST SP 800-95, Guide to Secure Web Services, provides more information on SOA security considerations. Scoping of Security boundary, assigning Risk Level and managing security expectations across stakeholders and getting aligned with agreement are few of the Security management challenges with SOA.

Specific Accreditation of Security Modules for Reuse

It provides developers trusted codes that can be reused when needed, at a reduced cost that must be relied upon to provide security functionality across a broad range of projects. Same process is described in NIST SP 800-37.

Cross-Organizational Solutions

It provides value and benefit to multiple organizations by providing access to memorandum of agreement or service-level agreement. MOA or SLA should specifically describe Security features, requirements and expected performance levels to ensure all parties are adequately protected. It should also talk about test and validation responsibilities, incident response procedures and monitoring and operations policies.

Technology Advancement and Major Migrations

As the technology advances the existing systems should also be migrated or upgraded to cope up with the current technology advancement. Consideration must be given not only to integrating security into the SDLC for new systems and the integration of systems, but also to the overhaul, upgrade, or migration of systems to address technology advancement.  

Data Center or IT Facility Development

It deals with the physical security solutions. Data centre is the storage upon which the applications are built. Customers using the data centre facility should only be provided with matrix of redundancy along with protection mechanism. Data at Rest and in-transit should be separated, along with features assisting in implementing Separation of Duties and Auditability should be strictly enforced. Like, Usage of VLANs for administrative traffic and applications.

Virtualization

The use of virtual machine is a great idea of cost saving. It can provide additional Security in terms of Isolation and Recovery, but needs additional planning for risk imposed due to virtualization implementation like Data Interception, DOS to host’s resources etc.

Above is the high level summary of NIST Special Publication on Security considerations in SDLC, assisting organizations by providing guidelines for building security into their SDLC process. This will help them to build cost effective, risk appropriate security control identification, development and testing.

 

Hack2Secure Secure SDLC program is completely based on different Industry security standards and practices, providing organizations an end-to-end solution to learn, adopt, integrate, implement and analyse Secure SDLC process. Our Secure SDLC workshop integrated with globally available Certification Program, equip professionals with required skills for Secure SDLC adoption. Hack2Secure exclusive Secure SDLC Consulting service assist organizations to adopt Secure SDLC framework and assist in integrating as a part of their process.

Download the Complete Article

Read More

Threat Modeling Process for Secure Design Implementation

Security in IT industry is a challenge in itself, and we have discussed some of them in our previous blogs. Security in an Application Design is important to keep the application secure from any vulnerabilities, low cost involvement in threat detection and minimizing the risk of redesigning the application. [Read: Secure the Design for Low Cost Security Implementation]

Now the question arises is HOW? How can this be done? How can an application design team discover and avoid vulnerabilities in their application? Well!! Among multiple methods available to analyse and evaluate Application Design Security, Threat Modeling is one of the most popular and widely implemented process. 

As mentioned by F. Swiderski and W. Snyder, in the Threat Modeling. Microsoft Press, 2004, “A threat is the adversary’s goal, or what an adversary might try to do to a system”.

Threats are NOT Vulnerabilities.

Threats Live forever, they are Attacker’s Goal

Threat Modeling is a structured, systematic and iterative approach of analysing security of an application. It can be taken as a process identifying potential threat that an attacker might use to identify gaps and vulnerabilities in the system. Threat Modeling is all about thinking from Attacker’s prospect and evaluate Security controls and resiliency.

Threat Modelling Process

A good Threat Model allows security architects to estimate the attacker’s entry point and attack complexity required to breach-in. It is an Iterative process that start from the design phase and typically continue throughout the development lifecycle. This is because it is almost impossible to identify threats in a single check. 

The threat modeling process usually involves 

  • Defining Assets or Resources to be protected
  • Identifying the entry or access points to these assets
  • Threat Analysis and associated Risk evaluation 
  • Development of mitigation strategies. 

Let’s discuss each step in brief:

Step 1: Define

  • Identify Security Objectives & Assets: 

Security objectives provide goals to ensure Core Security principles in a system viz. Confidentiality, Integrity, Availability, Authentication, Authorization and Accountability. These objectives help engineers to focus at each goal closely and evaluate entry point security resiliency against attacks. It will also identify critical assets like Servers, Processes, Systems, and Communication Interfaces.

Threat model can be designed for a particular system’s functionality or for a System as a whole. Security objectives defines scope of Threat Modeling process by defining critical assets.

  • Whiteboard the Architecture: 

At this stage the architect will create a diagram of the architecture on a white board. This will be defined in terms of person, process and data flow, which together will explain the structure of your application.

Step 2: Design

  • Define Attack Surface and Trust boundaries

Attack surface is the area where an attacker may conduct an attack while Trust boundaries are the locations where the level of trust changes. For example Network may form a trust boundary as Internet can be access by everyone but only trusted level will have access to the organization systems.

Once basic blueprint of System is defined, Attack surface and Trust boundaries should be declared to further scope the model objectives. Like, if we are defining Authentication mechanism in a system using 3rd party A.A.A. servers (e.g. Active Directory), we may not be worried about Security Attacks on them. But should consider threats related with communication channel and Data flowing from them.

  • Define Threats: 

In this step the designer will identify threats to the system that might compromise your security objective and effect your application.  This process involves analysing the assets and their attack goals, examination of entry and exit points, Applications feature and layer, and related communication channels. To conduct this process, security architects usually follow S.T.R.I.D.E. approach to examine object impact against different attacks.
Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service and Elevation of privileges.

Step 3: Measure

  • Prioritizing Threats: 

Initial Threats defined under Design Steps are quite elaborative. We need to define their scope and priority based on their Impact on System. Threat priority is usually depends on Risk and Cost of damage along with cost to fix. Both Direct and Indirect Risk (Reputation Loss, Brand & Trust Value etc) are considered in this case. 

  • Design Optimization for Threat Mitigation: 

Once, we have list of prioritized threats, next consideration should be done for different Security control adoption and design optimization to reduce/control/transfer Risk associated with these identified Threats. Small design changes related with adoption of security best practices or standards will assist in optimizing Threats at greater extend. 

  • Re-Validate Design: 

This is where integration of Threat Modeling actually starts. We may not get final design in one cycle as any change in old design may re-introduce different attack vector and threat. Architects needs to re-validate the design for applicable threats and the process goes on. 

Step 4: Document

After completion of process when design is agreed to be send for Implementation Phase, documentation or Reporting of complete exercise is to be done. This document is called as the Threat Model Report. This report is further utilized by the developers for the rest of the process as a reference. Report can also be shared with testing team to deduce applicable test scenarios.  

Threat Modeling Challenges

Although Threat Modeling is the most effective way to reduce the risk in an application, designers still face certain challenges while carrying out the whole process. Some of regular changes are like,

  • Process is Time Consuming
  • Requires Mature SDLC 
  • Advanced Skills and Real time exposure to different Threats
  • It is a Proactive measure which means it may not be directly related to business operations but will help organisation in long run.

Threat modeling process helps in mitigating all the risks that may occur in future, providing great level of security to the organisation. It helps to ensure that the security should be built into the system rather than addressed as an afterthought. It is a repetitive process and one needs to explore continuously to discover any new type of threat and attack to the system. 

Hack2Secure's Secure SDLC and Secure Design Services helps organisation in developing Threat Model and related processes. We assist organization to design, define, detect and analyse application architecture from Security prospect and assist in implementing appropriate Security controls and Risk optimization against related Threats to the application. 

We also assist professional and organizations in adopting it as a part of process and develop required skills with our Secure SDLC Workshop, accompanied by a globally deliverable and proctored Certification Program, SWADLP, assisting organizations to fulfil the exponentially increasing demand of Security Resources.
[Read: Equip Your Workforce To Counter Application Security Resource Gap ,  Industry need Resources with Secure SDLC skills

Read More

Security Requirement CheckList Considerations in Application Development

In our previous blogs, we have been discussing about Secure Software Development LifeCycle and ways to ensure Security across SDLC phases. [Read Blog: Integrating Security Across SDLC Phases] We have also discussed that Security should be integrated at the earlier stage of lifecycle instead of doing it later, which will reduce cost and risk of redesigning the software all over again. 
[Read Blog: Secure the Design for Low Cost Security Implementation]

To follow same, Process of integrating and ensuring Security should start from the very first stage, which is Requirement phase, where we gather Security Requirements, Build Checklist and Define Security definitions along with Quality Gates.

What is Requirement?

The IEEE Standard 729 defines requirements as: 

  • A condition or capability needed by a user to solve a problem or achieve an objective.
  • A condition or capability that must be met or possessed by a system…to satisfy a contract, standard, specification, or other formally imposed document.
  • It has been said that, Without Software Requirements, Software will Fail.  Without Secure Software Requirement, Organizations will.

Requirement Process in SDLC

Requirement Phase is the initial, most important and the fundamental phase of the SDLC. At this stage the development team or the management along with inputs from the sales team, domain experts and Marketing team, will gather information from the client about their requirements for the product. 

The process of Information gathering is done in 4 steps:

  • Feasibility Study
  • Requirement Gathering
  • Software Requirement Specification
  • Software Requirement Validation

All this information is recorded in a Requirement Document or Specification Sheet. This document will allow Engineers to understand what a product should do. It might include, Product overview; Specification of the functional, technical, economical and other operational environment of the product; the model that is to be used; a specification of the user interface; specification of how errors will be handled; and a listing of possible changes to the system. 

Secure Software Requirements

From Security prospect, Requirement Document should also capture, Product Security Requirements like Compliance needs, Industry Security Best Practices and any specific regulation to be followed from Industry or Deployment scenario. This document should also provide Security Definitions and Quality Gates, to ensure proper validation can be carried out.

Building Security Checklist is a challenging task, as Product specification may vary with respect to Industry, deployment environment and considered Standards. Broadly, we can categorize Checklist content to satisfy 4 areas of Application/Software Security viz. Core, General, Operational and Regulations. Let’s walk through these areas and have glimpse of same:
 
1.
Core Security Requirement

C.I.A. Triad [Confidentiality, Integrity and Availability] & A.A.A. [Authentication, Authorization and Accountability] are the core Security areas around which every product/software Security controls are defined.

Confidentiality: 

Confidentiality Requirements address protection against Disclosure of Sensitive Data to Unauthorized Individuals. We need to consider controls to ensure confidentiality is ensured when Data is at Rest, In-Transit and also when it is processed. Processes like Encryption, Steganography, Masking etc assist in assuring Data and Process Confidentiality. Security Checklist should contain specifications required to implement these like, Protocols to Use, Encryption Strength, usage of Processes ensuring confidentiality like Random Number Generator etc.

Integrity: 

Integrity requirements is needed to ensure Reliability and Accuracy of the information. Reliability can be ensured by checking software functionality and Accuracy can be ensured by checking that the data is modified by authorized person in authorized manner and by Ensuring that handled data is Complete and consistent. Implementation of Security Controls like Hashing, Digital Signatures assist in ensuring Integrity. Specifications like Protocols, Data Randomness Strength (e.g. Salt Length) etc should be captured as a part of Security Checklist.

Availability: 

Availability Requirements ensures protection against unwanted destruction or disruption of Service. These are tricky requirements and should be captured as a part of Service Level Agreement (SLA) components like measurement of Maximum Tolerable Downtime [MTD] and Recovery Time Objective [RTO]. 
Requirement sheet should also contain measures to define and analyses Business Stress Analysis [BIA]. These measures should be in both Quantitative (Cost to Fix/Restore, Legal Obligations etc) and Qualitative (Reputation Loss).

Authentication: 

We know, Authentication is all about ensuring llegitimacy and validity of the Identity. Requirement Document should clearly define Authentication requirements like which method to use (Digest, Token, Smart Card, Biometric), how Two Factor Authentication mechanism will flow, who will store and process sensitive data, any 3rd party mechanism to utilize (e.g. Active Directory), Single Sign-On (SSO) if needed etc.

Authorization: 

Authorization defines permissions to be assigned to All Authenticated entities. Security Checklist should capture how these Access will be granted like based on ROLES or RULES along with Granularity of them, Implementation of Best Practices like Least Privilege, Service Authorization etc. 

Accountability:

Accountability is all about building record of user action and act as Detective Control. It helps in detecting when Unauthorized User makes a Change, or when an Authorized User makes an unauthorized change. Security Requirement spec should clearly define logging and auditing Requirements, How-What-When to capture in accordance to Industry Security Standards and Best Practices. It should also define need of Storage, Rotation and Disposal of same.

2. General (Application) Security Requirements

From Application/Software Security prospect, General security requirements should capture proper Session, Error and Configuration management needs.

Session Management: 

Sessions are used to maintain state. In usual Application communication, on successful user/process Authentication, Session Identified (ID) is issued to Track authenticated state. It is compulsory when dealing with Stateless Protocols like HTTP. Product Security requirement sheet should capture methods and measures required to Secure Sessions. Requirements defining Uniqueness and Randomness of Session (Non-Guessable), Expiry, Non-reusability etc should be defined. 

Error Management:  

In Application, providing Errors and Traces are the part of usual process, when any un-wanted or un-scoped condition is encountered. From Security Prospect, we should clearly define what should be the level of information to be displaced in such scenarios to avoid Disclosure Threats like revealing of any Internal Application architecture, Design and Configuration Information.
 
Configuration management: 

Configurations drive application features and functionality. Specific practices and measures should be defined to avoid any Sensitive Data leakage and Security of these. Measures like Initialization and Disposal of Global Variables, Hashing/Encryption of Sensitive data etc should be clearly defined as a part of same.

3. Operational Security Requirements

Once Application/Software is developed and deployed, Security should also be considered when it is Operational in environment to avoid any unwanted disclosure or leakage. 

Deployment Environment: 

Security Requirement list should capture information about environment in which Software will be deployed and who will be using same. Environment Compliances and Industry Standard requirements are driven with this information. 

Archiving: 

Archiving is required to ensure Business Continuity, Regulatory Requirements and Organizational (Retention) Policy. It is important to capture archiving requirements to comply with organization’s policy and regulations. Measures like Where (media type) and How (online/offline, format, encryption) Data will be stored, Data retrieval policy etc should be clearly defined as part of requirement sheet.

Anti-Piracy: 

It is a part of Commercial off-the-shelf (COTS) requirement. It includes Code Obfuscation, Signing, Anti Tampering, Licensing, IP Protection mechanism. This requirement should be clearly addressed during Requirement Gathering to avoid any future disperancy and legal obligations.
4.
Some More Security Requirements

Sequencing & Timing: 

Sequencing and Timing design flaws can lead to Race Conditions or TOC/TOU Attacks. Race Windows, usage of Atomic Operations or Mutex Requirements (Mutual Exclusions or Resource Locking) must be identified as a part of Security Requirement

Procurement Needs: 

This is required to get proposals from qualified contractors. It should specify the scope of the desired procurement, define the evaluation process, and delineate the deliverables and requirements associated with the project.

International Regulation:

International Regulation and Compliance needs should also be discussed and captured as a part of Security Requirement Gathering.

So, now we can visualize, that it is very important to get the requirement phase correct and in-place in SDLC process. Cost of Implementing Security Control or measure identified in this phase will be negligible with respect to scenario, if any such flaw or requirement is detected in later stages. Requirements Analysis is a phase which should not be underestimated as it will lay the foundation of the project

Hack2Secure specifically focuses on this phase of the Secure SDLC process as we know the pros and cons of neglecting it. We pay special attention on this as a part of our projects and also assist organizations to adopt as a Checklist and Product Baseline Requirements. [Ref: Hack2Secure’s Secure SDLC oriented Service Document]. Before presenting it to the clients, Requirement document should be reviewed by Security Consultant and Assurance Team, Planning team, Project Managers and others. These people are continuously involved in this phase to monitor the process, Review and Perform Risk Management, if needed. 

Adding to same, our dedicated Secure SDLC Workshop assist professionals to acquire this skill. Hack2Secure has also recently launched a dedicated Certification program on Secure SDLC, proctored and delivered globally by PearsonVUE.

Read More

Secure the Design for Low Cost Security Control Implementation

Today, where new Security Threats are emerging at exponential rate, we require our assets, including Data and Systems to be protected. In current environment, Web Applications are considered as primary source of Security Attacks. One needs to adopt and implement different processes and controls to ensure it to have in-build protection to counter possible attacks against Confidentiality, Integrity and Availability of the Assets and should meet a set of defined security requirement. 
 
In traditional Software Development Lifecycle (SDLC), for a long time Security has not been considered as one of the major Requirement. It is usually considered in end of Testing Phase or under Review phase, when complete software of designed and developed. But today the scenario has been changed and Security is considered as one of the important Business requirement and organisations are adopting processes and methods to ensure Security from start i.e. from Requirement Phase itself, where collection of Security Requirements and development of Security assurance methodologies take place.

Design Phase

Most Security Defects are born during Implementation, where product blueprint is converted into functional reality. Although the most expensive ones, are those that are introduced in the Design phase due to ignorance of Security measures in product architecture for example by considering incorrect or in-adequate technology and control implementations. 

The Design phase is commonly defined as the set of actions that will translating detailed product requirements into complete, detailed Design vectors. This document focuses on how to deliver required functionality and act as instruction guide for Implementation phase. From Security prospects, it requires understanding of assets that needs to be protected, deployment environment, data flow, users who will access the assets, and all other possible gaps for the attacker. A proactive approach of paying close attention to security during the design phase prevents expensive redesign and yields substantial benefits during all later phases of the SDLC. 

Ensuring Secure Software Design is a challenging activity and must be performed with great care and clear goals. These goals can be defined by following Secure Design Principles and considerations, evaluating Attack Surfaces and performing Threat Modeling for analysis and Threat optimization.
 
Why do we need Secure Design?

There are many reasons why we do need secure Design in an application. 

  • Less Cost involved in Threat Detection and Management: 

Implementing Security controls have impact of both Product Cost and Schedule. Adopting Secure Design measures will reduce the relative cost and negative effects on security ROI to fix these vulnerabilities. 
Cost of fixing vulnerabilities is calculated to be 30 times as high as the cost to correct the faults at the design phase as per Microsoft SDL: Return-on-Investment doc. Additional costs may include a signi?cant loss of user productivity and confidence. And thereby reducing your total cost of software development. 

  • Minimal Re-design and Consistency: 

When application is developed with security in mind, there will be a minimal need to redesigning it. It will also reduce the chances of having the software redesign all over again, if the design is done at the early stage using standards for architectural design, which will in turn make the process more consistent. 

  • Ensures Defense-in-Depth: 

It will help to ensure defense-in-depth by assuring the multiple layers of security control at the earlier stage and providing the redundancy in case of any vulnerability attack. 

Increases Resiliency and Recoverability of the Software: 
Security Designed into software decreases the chances of attacks, which in turn assures resiliency and recoverability of the software. 

  • Added Reliability, Application is less prone to Attacks: 

By introducing Security in the design phase of an application, adds a sense of reliability and makes it less prone to attacks. You would know that your application has been designed securely and almost all the loopholes for the attacks is been checked and rectified. So there are a very less chances of attacks. It also makes the software easily maintainable. 

  • Business Logic Flaws can also be Addressed: 

Business logic flaws allows attacker to misuse the application by finding the gaps in the business rules. A Developer can address these business logic flaws at the design phase itself and can implement Security so that he can stop attacker taking advantages of the same.

  • Ensures “Build-In” motive, instead of “Bolt-it-on” Security:

Secure design will support the “Build-in” motive in security as opposed to “Bolt-it-on” at a later stage. The “Bolt-it-on” is a more costly, time consuming, and will generate low quality software. It is also at a later stage, is unreliable and inconsistent.  

  • Assist in detecting Architecture (Flaws) and Implementation (Bugs) issues: 

In design phase, as there is no coding done, developers are more concerned about the design issues related to software assurance. Threat modelling and secure architecture design review will help detecting both the architecture flaws and Implementation issues. 

  • Assist developers to Streamline Implementation: 

If Secure Designing is done properly then the developers will get sense of confidence in streamlining the next stage of implementation properly. 

Practices for Secure Design
There are certain Processes that one can use to apply Secure Design in SDLC Process. They are

  • Attack Surface Evaluation
  • Threat Modeling

Attack Surface Evaluation:-

Attack Surface is the measure of all the different point that is exposed to be exploited by a Threat Agent. Attack Surface evaluation attempts to enumerate list of features that an attacker will try to exploit. 

Threat Modelling :-

Threat modeling is a Systematic, Iterative and Structured technique to visualize all possible Threat Scenarios in existing design and then defining countermeasures to prevent or mitigate the effects of threats to the system. 

Threat modeling allows development teams to anticipate attacks by understanding how an adversary chooses targets (assets), locates design flaws in entry points and conducts an attack. A well-implemented threat model will identify the assets that need to be protected, what are the threats to these assets, the attack that could be used, and under what conditions the attacks will be successful. Not only is this important for identifying potential threats, but also in understanding what application defences must be defeated in order for a threat or series of threats to be realized.

Secure Software does not happen by accident, it required Security to be considered as Business issue, not as one of the Product Requirement for Compliances and Assurance. Security should not be addressed at the end of the product cycle, instead it must be ensured across the phases. [Read: https://www.hack2secure.com/blogs/integrating-security-across-sdlc-phases.] This will provide great level of Security to the enterprise.

Hack2Secure's Secure Design and Threat Modeling Service is a part of Secure SDLC Service Suite.  Where we assist organization to design, detect and analyze application architecture and design flaws. It provides a set of documents like security objectives, identification of relevant threats and corresponding countermeasures that can be used to create security specifications and security testing. 

Read More

Industry need Resources with Secure SDLC skills

Being an Organisation, are you worried about the security of your company’s data and other sensitive information? Well!! You should be. Looking at the increased rate of high profile cyber-attacks, even to some well-known big companies, like IBM, Sony, Facebook and many more, threat of cyber-attacks and its impacts are among the biggest worries of businesses today costing them billions of dollars annually along with the reputation loss.

Security Resource Crunch

The biggest reason for this is that the organisations do not have the right resources to handle situations like these. According to Michael Brown, CEO at Symantec, “The demand for the (cybersecurity) workforce is expected to rise to 6 million (globally) by 2019, with a projected shortfall of 1.5 million,”. A recent survey of IT decision makers across the U.S., Europe and Asia, it has been seen that now firms are aware about their resource crunch and are worried about data security and are bringing Security in the forefront of their challenges. This is the reason why Information Security jobs are the most in demand and the highly paid jobs in recent times.  For example the top paying cybersecurity job is a security software engineer with an average annual salary of $233,333, according to a recent report from the job board Dice. 

Requirements of Security Professionals

Organisations throughout Government, Finance and other industry are now hiring Experienced Security Professionals, who can prevent, detect and respond to the attacks coming their way. According to an analysis of Bureau of Labor Statistics data by the Peninsula Press in 2015, there are over 200,000 cyber security job openings in the U.S. 

Although organisations are ready to invest in the “right talent” to protect themselves from vulnerabilities, they are finding it really difficult to get skilled professionals who understands the current and cyber theft evolving environment. For example, businesses have a tough time finding talent for secure software development, intrusion detection, and attack mitigation. There are ample amount of IT Professionals in the market but a very few of them are experienced in Security domain.  The challenge in finding skilled professionals can be partially attributed to a lack of adequate training.  Hence companies are looking to hire Security expert professionals who can help them instantly instead of hiring IT Professionals and then give them training, as they do not have that much time and money to do so. Instead, they are preferring individuals with Professional degree with an add-on quality Certification in Information Security. 

Career in Information Security Domain

Right now, Industry is focusing on this skilled staff shortage issue and have started various educational programs and research facilities to meet the gap of Security resources. Yes it is true that it was difficult to find the right training a decade ago, but it is not the case anymore. Today there are many accredited universities, colleges, technical and trade schools offering courses in different information security domains likes, testing, coding architects, developers etc. 

The career scope of information security is perhaps highest in the domain of information technology (IT). If you have any of the InfoSec Certifications that means you have a career set ahead of yourself. There are almost endless gamut of options and specialities to you to choose from. Looking at the demand for this you will never be unemployed in this domain. You just need to be enthusiasts enough always to research and learn about new tools and technologies that might give you edge over others.

Secure SDLC can help

Organisations are focusing now in applying Security from the scratch of Application/Product/Software Development, so that there is no loopholes for hackers to attack later. In this situation where organisations are struggling hard to find experienced Security professionals, they have now turned towards their existing workforce, to adopt similar skills based on their roles and responsibilities and have also started on adoption of Security processes and standards to implement build-in security measures in their Product. Secure SDLC program can assist in this, which is all about integrating and ensuring Security at every phase of Development Lifecycle and can surely help to secure the software from being exploited by hackers. Secure SDLC can help organisations across different domains like Developers, Architect, testers etc. Secure SDLC trained Professionals can ensure low cost build-in Security controls aligned with Security Standards and compliances. This not only save organisations money but also reduces possible attack surfaces leading to attack scenarios. 

Importance of Secure SDLC Certification

We can see, adoption of Secure SDLC process is an important necessity of an organisation. And companies are preferring individuals with Security Certifications over IT Professionals. Secure SDLC Certification will add feather to your crown by giving you extra knowledge in your domain and adding on to your existing skills. Experienced Individuals can take Secure SDLC Training to add on to their existing skill set which will increase their market value and make them industry ready. For example, if you are a Developer you can learn Security coding, If you are a tester, then you can learn about Security Testing, Architects can learn about Secure Design Principles and Methodologies, not only that if you are from the management side then also you have an option to get learning in Risk Management and requirements Domain. To put this in a simple word, Secure SDLC has scope for everyone to fulfil all business objectives.

Read More

Equip Your Workforce To Counter Application Security Resource Gap

Currently numerous web/mobile and cloud applications are available in the market with different capabilities to perform multiple task at a time. These applications are prepared with lots of hard work and dedication. But along with the development of applications, their exploitation is also occurring at large level. Malicious People are continuously pushing their efforts to breach the Program/Application data by bypassing its security. This has compelled, Software Development companies to included Security in their primary focus list along with Software Feature and Functionality, to defend against ever-rising possible Threats in their application. Every day, we need to research and develop new Security programs and Countermeasures against these threats, making Jobs in cyber security domain to grow 74% times faster than IT jobs, leading to big Security skill-crunch and Resource Gap in this domain. US News and World Report ranked a career in information security analysis fifth on its list of best technology jobs.

Application Security Resource Gap

At present, there is a great demand of Information Security experts in the sectors like IT, finance, manufacturing and defence services. But the supply is not sufficient as compare to the demand. This situation has occurred because institutions offering Information Security programs are very less in number. Right now, Industry is focusing on this shortage and have started various educational programs and research facilities to meet the gap of Security resources. Secure SDLC program is one of them, which assist in integrating and ensuring Security at every phase of Development Lifecycle and can surely help to secure the software from being exploited by hackers. Organizations have now started to equip their resources with Secure SDLC process and procedures according to their Roles, so individual can “build-in” security in a product as per their roles in development lifecycle.

Secure Software Development Life Cycle [Secure SDLC]   

The Software development life cycle is defined as a structure of well organised sequence to develop the software projects. Secure SDLC is a small integration of Security in these sequenced steps. Some steps which need to be followed to complete the whole process are listed as below:-  

Security Requirements
First of all the Security Requirement is monitored that which Level of security is needed for the Application, what are Security Compliance Requirements, Standards to follow etc. On the bases of requirement, a Phase Gate is settled to monitor and manage the risk.

Secure Design
After gathering all the information regarding security requirements, application’s blueprint or structure is to be defined. It should include information about every possible Threat applicable to the design and impose security controls accordingly.

Secure Coding
The process of secure coding is initiated to make a secure program. In this procedure, Security Coding Best Practices are followed to improve the quality of software. After Coding of every functional chunk, review of program against security checkpoints and programming flaws should be done.

Security Testing
After the construction of whole program, test of its vulnerability is performed to check the faults. In this process, possible security gaps are identified which may be responsible for future attacks. It recognizes the full capability of a program under extreme circumstances.

Deployment
After testing the program in every positive and negative situations, it is then deployed. Its compatibility is reviewed after configuring it with company server. At this stage network architecture suitability with the industry is also checked. All possible weaknesses are identified in deployment that a hacker might use to bypass the Security.

Need of Secure SDLC
The gap of resources ion Application Security has increased because most part of the world is unknown to the ever-increasing threats and possible attack scenarios. Hackers today are continuously discovering new exploits to harm applications. To counter this, application development companies have to upgrade their security programs with new features. Big companies are mostly targeted by the cyber criminals to steal their valuable data or exploit their existing application which automatically decrease their market value. Due to the lack in availability of professional cyber security experts, companies are now facing concerns like Ransomware, Software Piracy, Data Leakage etc or to the worse, some are now dependent on illegal hacker’s services unwillingly. They have to share their confidential information with hacker to protect the company from any possible threat.

Procedure to Train the work force

  • Existing work force is much familiar to the threats which their product may face. A company can train their workforce to counter the possible cyberspace threats.
  • First of all implement Security as a Business Process, ideally processes like Secure SDLC should be implemented to Build-in Secure Software instead of relying Bolt-on Security controls at the time of Deployment.
  • Introduce Security definitions, define Risk Handling Criteria and assign Responsibilities according to individual Role in application Development. For example Assurance team should be equipped with proper Security Checklist and must define Security Gates and qualification criteria, while Development Team should be aware of Secure Coding practices and guidelines.
  • Determine the threats which are currently affecting or are possible on an Application. Procedures like Threat Modeling assist a lot in achieving the same. Workforce must be creative enough to find the unique solutions because of the flexibility of challenges. Every new threat could be different from the previous one. So the members must be dependent on their own creative mind instead of traditional knowledge.
  • Prepare a team and provide them diverse training and knowledge to perform different activities. Training must be a continuous process because every day new threat may arise which needs new training skills. A centralized Security Office or Team or Interest Group with individuals from specialized roles can be formed for appropriate and effective decision making.
  • Workforce must continuously monitor the threats attacking on their applications, especially related with 3rd party libraries. Along with this activity, team must be flexible enough to give priority for current situation.
  • Companies have also now understood the importance of Security Integration as a process and have now started considering individuals with Security knowledge over others. This has open new set of opportunities with individuals to adopt career in Information Security. Now, instead of taking it as a separate domain, they can now easily top-up their existing skills with required Security processes and methodologies to achieve new professional heights.

Hack2Secure understands the need of Security in an Application Development process and has come up with a unique Secure SDLC program and developed Security services across it. As a part of the same, we also deliver dedicated Workshop and Certification programs based on globally recognized Industry Security Standards and best practices from NIST, OWASP, CERT, PCI-DSS etc.

Secure Web Application Development Life Cycle Practitioner (SWADLP) Certification program is delivered and proctored globally via Pearson Vue, to evaluate individual's implementation level skills in Security practices required to ensure Secure Application Development.

Read More

Integrating Security Across SDLC phases

Today, Hackers are continuously looking for any vulnerability, flaw or weakness in an application that could be exploited to compromise the security of it. This exponential increase in number of Security attacks and Vulnerabilities, has ensured Security Assurance is taken as one of the primary requirement in an organization.

Integrating security into the development of an application or software is necessary to decrease its risk of susceptibility to attacks and exploits. Traditional methods of security testing were performed on a finished product. However, with the rise in the intensity and the number of attack vectors, it has become necessary for organizations to include it as a part of every phase of an SDLC.

Software Development Lifecycle, is a process which defines the various steps involved in the development of a software. It is adopted as a standard procedure by organizations to meet the industry requirements and deliver high-quality and secure software. The aim behind having a well-defined procedure is to meet the customer expectations within the specified timelines and cost estimates.

Looking at the different aspects of it including threat modeling, peanalysis, secure design and secure coding practices,Secure SDLC can be an intimidating task.There are various models of SDLC, like Agile, Waterfall, V-Shaped, iterative and more, are defined and developed according to the industry requirements. However, the flow of a typical SDLC consists of 7 stages. Let’s discuss these phases in brief and explore Security considerations in each phase:

 

Secure SDLC: Phases

1. Security Training & Awareness: This is the first step towards Secure SDLC, where we build Security aware workforce. It is very important for an organization to educate its workforce about Security Concepts, possible threats and attack scenarios so that they will be able to define and evaluate security Risk and Definitions. Training and Awareness programs needs to be organized to learn about Security Assurance and methodologies, Security Policy, Procedure and Best practices. 

2. Building Security Requirements: Establishing correct security requirements is often a hard learned lesson but is very important for software development in order to avoid any confusions later. It includes preparing Security checklist, integrating Security in Quality Gates, preparing Product Security Baselines along alignment with Security Models and Standards.

3. Secure by Design: Using the prepared Requirement document, product architectures are designed. From Security prospect, it should be designed to combat any possible Security Threat. Processes like, Threat modeling will help you to analyze Attack surfaces and possible threat scenarios in existing product design.

4. Secure Implementation & Coding: In development stage, where Security Control implementation takes place, usage of secure coding practices is equally important. Ensuring Security in Code review process and analyzing standard checkpoints generally occurred at this stage to ensure it has the features and functions securely specified.

5. Security Verification/Testing: In testing stage, the developed product is evaluated to handle possible security attacks and vulnerabilities or Security defects. A dynamic analysis of the product should be done by testing its security components to detect the loopholes. Different security testing tools, techniques and methodologies are required to verify Security of the product.

6. Security Review & Response Plan: Even after so many precautions and testing, unexpected errors may crop up in the product. To reduce the later risk, Security engineers may have to build Final Security Review Plan. This plan includes tasks like Auditing, VA-PT, and Incident Handling. Organizations should have dedicated skilled staff who should be responsible for Deployment and Procurement Risk.

7. Security Maintenance: Every software needs regular maintenance to keep up date with new technologies and tools and emerging attacks. Organizations should have a maintenance plan ready to provide customer’s after service help. Security maintenance includes handling 3rd Party Vulnerabilities, Security Escalation & Patch Management Plan and Application Disposal: Policies, Criteria & Process.

The above mentioned process defines that by integrating Security at every phase of development process is essential for developing secure software and will further reduce overall Security Control Implementation cost, Handle Active and Passive Losses etc. Apart from this, educating your workforce on Security awareness, secure coding best practices and available frameworks will help you to avoid risk at the very first place.

Hack2Secure understands the need of Security in an Application Development process and has come up with a unique Secure SDLC program and developed its Security services across it.

For more details on Secure SDLC Services,Click Here 

We also provide Workshop and Certification program on Secure Software Development Lifecycle based on globally recognized Industry Security Standards and best practices from NIST, OWASP, CERT, PCI-DSS etc. This program assist an individual with enormous opportunities to learn about SDLC, and will give you hands-on exposure and relevant Case Studies to assist in integrating Security at every phase of Web Application Development Lifecycle.

For more Details on Secure SDLC Workshop, Click Here 

Secure Web Application Development Life Cycle Practitioner (SWADLP) Certification program is delivered and proctored globally via Pearson Vue world’s largest online Testing Organization, to evaluate individual's implementation level skills in Security practices required to ensure Secure Application Development. It will ensures candidate's awareness on Application Security Challenges, Threats, Standards, Best Practices and assurance methodologies along with hands-on implementation level knowledge and skill-sets.

For more Details on Secure Web Application Development Lifecycle Practitioner (SWADLP) Certification, Click Here 

Hack2Secure provides the overall solutions to organizations that will be helpful for you to develop a secure, flawless and threat free Application, and make your product differentiated from others. Organization needs to understand that securing your SDLC is a continuous process and not a one time job. It will help them to pay attention to every single detail and perform in a structured manner so as to minimize threats or entry points for an attacker.

    Book an Exam  Contact Us  Enquire Now !