(My) CSSLP Notes – Secure Software Design

Note: This notes were strongly inspired by the following books: CSSLP Certification All in one and Official (ISC)2 Guide to the CSSLP CBK, Second Edition

Design Process

Attack Surface Evaluation

A software or application’s attack surface is the measure of its exposure of CSSLP-logobeing exploited by a threat agent i.e., weaknesses in its entry and exit points that a malicious attacker can exploit to his or her advantage.
The attack surface evaluation attempts to enumerate the list of features that
an attacker will try to exploit.

Threat Modeling

Threat modeling is the process used to identify and document all the threats to  system.

The threat modeling process have 3 phases:

  1. model the system for which you want to find the threats.
  2. find the threats.
    1. STRIDE model.
    2. attack trees – An attack tree is a hierarchical tree-like structure, which has either an attacker’s objective (e.g., gain administrative level privilege, determine application makeup and configuration, bypass authentication mechanisms, etc.) or a type of attack
      (e.g., buffer overflow, cross site scripting, etc.) at its root node.
  3. address each threat found in the previous step. Once identified,each threat must be evaluated according to the risk attached to it. There are several ways to quantitatively or qualitatively determine the risk ranking for a threat. These range from the simple, non-scientific, Delphi heuristic methodology to more statistically sound risk ranking using the probability of impact and the business impact.
  4. document and validate.

More details about threat modeling can be found here : Threat Modeling for mere mortals and (My) OWASP BeNeLux Days 2016 Notes – Training Day.

Design Considerations

This part is linked to the Secure Software Concepts and contains how the security software concepts can be applied to have a secured application.

  • confidentiality – use cryptographic and masking techniques
  • integrity – use hashing (or hash functions), referential integrity design (uses primary keys and related foreign keys in the database to assure data integrity), resource locking (when two concurrent operations are not allowed on the same object (say a record in the database), because one of the operations locks that record from allowing any changes to it, until it completes its operation, it is referred to as resource locking), and code signing.
  • availability – replication, fail-over and scalability techniques can be used to design the software for availability.
  • authentication – use multi-factor authentication and single sign on (SSO). Rely of already existing mechanism if possible (like the ones offered by the operating system).
  • authorization – rely of already existing mechanism if possible.
  • accounting (audit) – determine of what elements should be logged and under what circumstances.
Some of the common, insecure design issues observed in software are the
following:
  • improper implementation of least privilege
  • software fails insecurely
  • authentication mechanisms are easily bypassed
  • security through obscurity
  • improper error handling
  • weak input validation

Architecture system with secured design principles:

  • good enough security – care should be taken to ensure that the security elements are in response with the actual risk associated with the potential vulnerability; do not over-engineer.
  • least privilege – use of accounts with non-administrative abilities.
    Modular programming is a software design technique in which the entire program is broken down into smaller sub-units or modules. Each module is discrete with unitary functionality and is said to be therefore cohesive, meaning each module is designed to perform one and only one logical operation.
  • separation of duties – the programmer should not be allowed to review his own code nor should a programmer have access to deploy code to the production environment.
  • defense in depth
    • use of input validation along with prepared statements or stored
      procedures, disallowing dynamic query constructions using user
      input to defend against injection attacks.
    • disallowing active scripting in conjunction with output encoding
      and input- or request-validation to defend against Cross-Site
      Scripting (XSS).
  • fail safe
    • the user is denied access by default and the account is locked out after the maximum number (clipping level) of access attempts is tried.
    • errors and exceptions are explicitly handled and the error messages are non-verbose in nature.
    •  not designing the software to ignore the error and resume next
      operation
  • economy of mechanism – trade-off that happens between the
    usability of the software and the security features that need to be designed and built in.
    • Unnecessary functionality or unneeded security mechanisms should be avoided.
    • Strive for simplicity.
    • Strive for operational ease of use.
  • complete mediation
  • open design – the inverse of the open design principle is security through obscurity, which means that the software employs protection mechanisms whose strength is dependent on the obscurity of the design.
  • least common mechanism – mechanisms common to more than one user or process are designed not to be shared. Design should compartmentalize or isolate the code (functions) by user roles, since this increases the security of the software by limiting the exposure.
  • psychological acceptance – security principle that states that security mechanisms should be designed to maximize usage, adoption, and automatic application.The security protection mechanisms:
    • are easy to use,
    • do not affect accessibility.
    • are transparent to the user.
  • weakest link – when designing software, careful attention must be
    given so that there are no exploitable components.
  • leverage existing components – reusing tested and proven, existing libraries and common components has good security benefits.

Securing commonly used architectures

  • mainframe architecture
  • distributed architecture
    • client/server
    • p2p
  • service oriented architecture
    • An ESB is a software architectural pattern that facilitates communication between mutually interacting software application.
    • web-services
      • SOAP
      • REST
  • rich internet aplications (RIA)

Service models:

  • Infrastructure as a Service (IaaS)  -infrastructural components such as networking equipment, storage, servers and virtual machines are provided as services and managed by the cloud service provider.
  • Platform as a Service (PaaS) -in addition to infrastructural components, platform components such as operating systems, middleware and runtime are also provided as services and managed by the cloud service provider.
  • Software as a Service (SaaS) – in addition to infrastructural and platform components, data hosting and software applications are provided as services and managed by the cloud service provider.

Digital Rights Management

The expression of rights is made possible by formal language, known as Rights Expression Language (REL). Some examples of REL include the following:
  • Open Digital Rights Language (ODRL)  – A generalized, open standard under development that expresses rights using XML.
  •  eXtensible rights Markup Language (XrML) – Another generalized REL that is more abstract than ODRL. XrML is more of a meta-language that can be used for developing other RELs.
  • Publishing Requirements for Industry Standard Metadata
    (PRISM) – Unlike ODRL and XrML, PRISM can be used to express
    rights specific to a task and is used for syndication of print media
    content such as newspapers and magazine.

Trusted computing:

  • Trusted Platform Module (TPM) – specification used in personal computers and other systems to ensure protection against disclosure of sensitive or private information as well as the implementation of the specification itself.
  • Trusted Computing Base (TCB) – the set of all hardware, firmware and software components that are critical to its security.

(My) CSSLP Notes – Secure Software Requirements

Note: This notes were strongly inspired by the following books: CSSLP Certification All in one and Official (ISC)2 Guide to the CSSLP CBK, Second Edition

 Policy Decomposition

CSSLP-logoThe policy decomposition is the process of breaking down high level policy requirements into security objectives and eventually protection needs and secure software requirements.

Policies involving protecting data could be decomposed in confidentiality requirements.

Policies involving protecting data from unauthorized alteration can be decomposed in integrity requirement.

Policies associated with determining access can be decomposed into availability requirements.

policy decomposition

Data Classification and Categorization

Data classification is a risk management tool, with the objective to reduce the costs associated with protecting data.

Types of data :

  • structured – the most common form of structured data is that stored in the DB; other forms of structured data, XML, JSON test files, log files.
  • unstructured – the rest of data that is not structured; data that is not easily parsed and parsed.

Data states :

  • data at rest.
  • data in transit – data being transmitted from one location to another.
  • date being created.
  • data being changed or deleted.

Data labeling

Data classification/labelling is the conscious effort to assign labels (a level of sensitivity) to information (data) assets, based on potential impact to confidentiality, integrity and availability (CIA).

The main objective of data classification is to lower the cost of data protection
and maximize the return on investment when data is protected.

Data ownership:

  • Data Owner – (also called information owner or business owner) is a management employee responsible for ensuring that specific data is protected. Data owners determine data sensitivity labels and the frequency of data backup. The Data Owner is responsible for ensuring that data is protected. A user who “owns” data has read/write access to objects.
  • Data Custodian – provides hands-on protection of assets such as data. They perform data backups and restoration, patch systems, configure antivirus software, etc. The Custodians follow detailed orders; they do not make critical decisions on how data is protected.

Requirements

Role and user definitions

  • objects – items that a user (subject) interacts with in the operation of a system.
  • subjects – an active entity on a data system. Most examples of subjects involve people accessing data files. However, running computer programs are subjects as well. A Dynamic Link Library file or a Perl script that updates database files with new information is also a subject.
  • actions – permitted events that a subject can perform on an associated object.
The subjects represent who, the objects represents what and actions represent the how of the subject-object-activity relationship. A subject-object matrix is used to identify allowable actions between subjects and objects based on use cases.
Once use cases are enumerated with subjects (roles) and the objects (components) are defined, a subject-object matrix can be developed. A subject-object matrix is a two-dimensional representation of roles and components.

Functional requirements

Functional requirements describe how the software is expected to function. They begin as business requirements and are translated into functional requirements.

Uses cases are a technique for determining functional requirements in developer-friendly terms. Use case modeling is meant to model only the most significant system behavior or the most complex ones and not all of it and so should not be considered as a substitute for requirements specification documentation.
 From use cases, misuse cases can be developed. Misuse cases, also known as abuse cases help identify security requirements by modeling negative scenarios.
Time of Check/Time of Use (TOCTOU) attacks are also called race conditions: an attacker attempts to alter a condition after it has been checked by the operating system, but before it is used. The term race condition comes from the idea of two events or signals that are racing to influence an activity.
Some of the common templates that can be used for use and misuse case
modeling are templates by Kulak and Guiney. On the tooling side you can take a look to Secure Quality Requirements Engineering (SQuaRE) methodology.

Requirements Traceability Matrix (RTM)

The RTM is a grid that assists the development team in tracking and managing requirements and implementation details.

A generic RTM is a table of information that lists the business requirements in the left most column, the functional requirements that address the business requirements are in the next column. Next to the functional requirements are the testing requirements. From a software assurance perspective, a generic RTM can be modified to include security requirements as well. This is a template example of RTM diagram: Requirements Traceability Matrix Template

(My) OWASP Belgium Chapter meeting notes

These are my notes of OWASP Belgium Chapter meeting of 16th of June.

OWASP Summit 2017 debrief

The talk was a debrief about the OWASP Summit 2017 which was held in London; more than 200 participants, 176  working sessions, 6 rooms. To see all the outcomes of the summit you can check the Summit Outcomes.

Some info about some of the discussed topics:

  • OWASP Top 10 2017
    • discussions about the process
    • have a broader audience, not developers only
    • more can be found here.
  • mobile security testing guide
    • guide updated
    • new content added; more topics like the best practices for use of OAUTH2 (??)
    • more can be found here.
  • define agile security practices
    • participants redefined the session goals to discuss security practices for agile development teams.
  • SAMM 2
    • more can be found here.
  • app sec education
    • what is the perfect/best curriculum to teach app sec at school.
  • security GitHub integration
    • drafted a letter to be able to  reach out github with a request for comment.
    • more can be found here.
  • threat modeling (TM) sessions
    • OWASP wants to be more visible on threat modeling.
    • TM OWASP pages revamp
    • TM templates
    • TM iot devices
    • TM diagram techniques
    • TM cheat sheets & lightweight TM
    • new slogan: “The sooner the better, never too late”
  • OWASP playbook series
    • actionable consistent process to getting started with various application security topics.
    • more can be found here, here and here.
  • OWASP Testing guide v5

Threat modeling lessons from Star Wars

This is an introductory talk about threat modeling having as goal to demystify the threat modeling is hard and can be done only by very smart/trained people.

You can start to threat model by answering 4 questions:

  1. What are you building?
    • You must represent/draw somehow the item that you want to build.
    • The DFDs (data flow diagrams) are the most common way to represent the system under build but other options are available like Swim Lanes diagrams.
    • You can use any kind of diagram that fits your needs.
  2. What can go wrong?
    • Find the threats using STRIDE, Attack Trees, CAPEC Kill chain, Check Lists.
    • A small introduction to STRIDE mnemonics was done.
  3. What are you going to do about it?
  4. Did you do an acceptable job at 1-3?

The second part of the talk was called “Top 10 lessons” and actually contained a list of 10 misconceptions about the threat modeling:

  1. Think like an attacker
    • it is very difficult to think like an attacker doesn’t help you to know what you have to do.
  2. You’re never done threat modeling
    • the 4 states of a threat modeling:
      • model
      • identify threats
      • mitigate
      • validate
  3. The way to threat model is…
    • should focus on what delivers value by helping people find good threats
    • for each threat modeling phase (model, identify, mitigate, validate) there are different techniques to do the job.
  4. Threat modeling as one skill
    • there are different techniques : DFDs , Attack trees, etc…
  5. Threat modeling is born not taught
    • threat modeling is like playing a violin; you need to train yourself and you will not be able to play correctly from the beginning.
    • practice, practice, practice
  6. The wrong focus
    • focus on the software being build not on the assets that you want to protect or by thinking about your attackers.
  7. Threat modeling is for specialists
    • threat modeling should be like version control, anyone can and should threat model.
  8. Threat modeling without context
    • see threat modeling not in a vacuum but as part of a chain, that can help different teams (dev team, operations team) to fix (security) problems.
  9. Laser like focus on threats
    • requirements drive threats.
    • threats expose requirements.
    • threats needs mitigations.
    • un-mitigatable threats drive requirements.
  10. Threat modeling at the wrong time
    • you must start threat modeling early.

Main take-aways: anyone can threat model and should; all the necessary technique can be learned.

5 (software) security books that every (software) developer should read

I must admit that the title is a little bit catchy; a better title would have been “5 software security books that every developer should be aware of“. Depending on your interest you might want to read entirely these books or you could just know that they exists. There must be tons of software security books on the market but this is my short list of books about software security that I think that each developer that is interested in software security should be aware of.

Hacking – the art of exploitation This book explains the basics of different hacking techniques, especially the non-web hacking techniques: how to find vulnerabilities (and defend against)  like buffer overflow or stack-based buffer overflow , how to write shellcodes, some basic concepts on cryptography and attacks linked to the cryptography like the man-in-the-middle attack of an SSL connection. The author tried to make the text easy for non-technical peoples but some programming experience is required (ideally C/C++) in order to get the best of this book. You can see my full review of the book here.

Iron-Clad Java: Building secure web applications This book presents the hacking techniques and the countermeasures for the web applications; you can see this books as complementary of the previous one; the first one contains the non-web hacking techniques, this one contains (only) web hacking techniques; XSS, CSRF, how to protect data at rest, SQL injection and other types of injections attacks. In order to get the most of the book some Java knowledge is required. You can see my full review of the book here.

Software Security-Building security in  This books explains how to introduce the security into the SDLC; how to introduce abuse cases and security requirements in the requirements phase, how to introduce risk analysis (also known as Threat Modeling) in the design phase and software qualification phase. I really think that each software developer should at least read the first chapter of the book where the authors explains why the old way of securing application (seeing the software applications as “black boxes” than can be protected using firewalls and IDS/IPS) it cannot work anymore in the today software landscape. You can see my full review of the book here: Part 1, Part 2 and Part 3.

The Tangled Web: A Guide to Securing Modern Web Applications This is another technical book about security on which you will not see a single line of code (the Software Security-Building security in is another one) but it highly instructive especially if you are a web developer. The book presents all the “bricks” of the today Internet: HTTP, WWW, HTML, Cookies, Scripting languages, how these bricks are implemented in different browsers and especially how the browsers are implementing the security mechanism against rogue applications. You can see my full review of the book here.

Threat modeling – designing for security Threat modeling techniques (also known as Architectural Risk Analysis) were around for some time but what it has changed in the last years is the accessibility of these technique for the software developers.  This book is one of the reasons for which the threat modeling is accessible to the developers. The book is very dense but it  suppose that you have no knowledge about the subject. If you are interested in the threat modeling topic you can check this ticket: threat modeling for mere mortals.

(My) OWASP Belgium Chapter meeting notes

These are my notes of OWASP Belgium Chapter meeting of 29th of May.

HTTP for the good or the bad

The talk was about the (mostly php) webshells and how the bad guys are using it.

(Webshels) common features :

  • file manipulation
  • system command execution
  • DB administration
  • network scanning

How the bad guys are trying to protect the access to the webshell url once is installed on the vulnerable servers:

  • obfuscation
  • use random get parameters
  • use the .httpaccess file – use the
  • user agent
  • fully qualified domain names
  • (HTTP) referrer header
  • custom HTTP headers – use custom HTTP header to grant access to the webshell url.
  • fake arguments
  • IP geolocalisation – used an external service to geolocalize the connected client.
  • black listed IPs – use the (black) list of IPs from which the client cannot connect.

(Common) mistakes made by the webshell developers:

  • use deprecated functions.
  • all of them are suffering from the XSS vulnerabilities (but are hard to be exploited).
  • no httpOnly cookies.
  • weak authentication; no password protection against brute-force attack.
    • the check of th password is done via a hash check (very often the real password is in the code as comment).

 

Panopticon – a cross-patform dissambler

Panapticon goals:

  • disassemble the code
  • do a static analysis of the code
  • have a very user friendly UI.

Panapticon “special” features:

  • semantic-based analysis; approximative what happens at run time without executing the code.
  • display, compare and run execution traces.
  • scripting support:Ruby/Python/Js

Book review : The Tangled Web: A Guide to Securing Modern Web Applications

This is a review of the The Tangled Web: A Guide to Securing Modern Web Applications book.tangledwebbook

(My) Conclusion

This books makes a great job explaining how the “bricks” of the Internet (HTTP, HTML, WWW, Cookies, Script Languages) are working (or not) from the security point of view. Also a very systematic coverage of the browser (in)security is done even if some of the information it starts to be outdated. The book audience is for web developers that are interested in inner workings of the browsers in order to write more secure code.

Chapter 1 Security in the world of web applications

This goal of this chapter is to set the scene for the rest of book. The main ideas are around the fact that security is non-algorithmic problem and the best ways to tackle security problems are very empirical (learning from mistakes, develop tools to detect and correct problems, and plan to have everything compromised).

Another part of the chapter is dedicated to the history of the web because for the author is very important to understand the history behind the well known “bricks” of the Internet (HTTP, HTML, WWW) in order to understand why they are completely broken from the security point of view. For a long time the Internet standards evolutions were dominated by vendors or stakeholders who did not care much about the long-term prospects of technology; see the Wikipedia Browser Wars page for a few examples.

Part I Anatomy of the web (Chapters 2 to 8)

The first part of the book is about the buildings blocks of the web: the HTTP protocol, the HTML language, the CSS, the scripting languages (JavaScript, VBScript) and the external browser plug-ins (Flash, SilverLight). For each of these building blocks, the author presents how are implemented and how are working (or not) in different browsers, what are the standards that supposed to drive the development and how these standards are very often incomplete or oblivious of security requirements.

In this part of the book the author speaks only briefly about the security features, knowing that the second part if the book supposed to be focused on security.

Part II Browser security features (Chapter 9 to 15)

The first security feature presented is the SOP (Same Policy Origin), which is also the most important mechanism to protect against hostile applications. The SOP behaviour is presented for the DOM documents, for XMLHttpRequest, for WebStorage and how the security policies for cookies could also impact the SOP.

A less known topic that is treated is the SOP inheritance; how the SOP is applied to pseudo-urls like about:, javascript: and data:. The conclusion is that each browser are treating the SOP inheritance on different ways (which can be incompatible) and it is preferable to create new frames or windows by pointing them to a server-suplied blank page with a definite origin.

Another less known browser features (that can affect the security) are deeply explained; the way the browsers are recognizing the content of the response (a.k.a content sniffing), the navigation to sensitive URI schemes like “javascript:”, “vbscript:”, “file:”, “about:”, “res:” and the way the browsers are protecting itself against rogue scripts (in the case of the rogue scripts protection the author is pointing the inefficiently  of the protections).

The last part is about different mechanisms that browsers are using in order to give special privileges to some specific web sites; the explained mechanisms are the form-based password managers, the hard-coded domain names and the Internet Explorer Zone model.

Part III Glimpse of things to come (Chapter 16 to 17)

This part is about the developments done by the industry to enhance the security of the browsers,

For the author there are two ways that the browser security could evolve; extend the existing frameworks/s or try to restrict the existing framework/s by creating new boundaries on the top of existing browser security model.

For the first alternative, the following solutions are presented: the W3C Cross-Origin Resource Sharing specification , the Microsoft response to CORS called XDomainRequest  (which by the way was deprecated by Microsoft) and W3C Uniform Messaging Policy.

For the second alternative the following solutions are presented: W3C (former Mozilla) Content Security Policy , (WebKit) Sandboxed frames and Strict Transport Security.

The last part is about how the new planned APIs and features could have impact on the browser and applications security. Very briefly are explained the “Binary HTTP”, WebSocket (which was not yet a standard when the book was written), JavaScript offline applications, P2P networking.

Chapter 18 Common web vulnerabilities

The last chapter is a nomenclature of different known vulnerabilities grouped by the place where it can happen (server side, client side). For each item a brief definition is done and links are provided towards previous chapters where the item has been discussed.

(My) CSSLP Notes – Secure Software Concepts

Note: This notes were strongly inspired by the following book: CSSLP Certification All in one.

General Security Concepts

BasicsCSSLP-logo

The security of IT systems can be defined using the following attributes:

  • confidentiality – how the system prevents the disclosure of information.
  • integrity – how the system protects data from the unauthorized access.
  • availability – access to the system by authorized personnel.
  • authentication – process of determining the identity of a user. Three methods can be used to authenticate a user:
    • something you know (ex: password, pin code)
    • something you have (ex: token, card)
    • something you are (ex: biometrics mechanisms)
  • authorization – process of applying access control rules to a user process to determine if a particular user process can access an object.
  • accounting (auditing) – records historical events on a system.
  • non-repudiation – preventing a subject from denying a previous action with an object in a system.

System principles

  • session management – design and implementation of controls to ensure that the communications channels are secured from unauthorized access and disruption of communications.
  • exception management – the process of handling any errors that could appear during the system execution.
  • configuration management – identification and management of the configuration items (initialization parameters, connection strings, paths, keys).

Secure design principles

  • good enough security – there is a trade off between security and other aspects associated with a system. The level of required security must be determined at design time.
  • least privilege – a subject should have only the necessary rights and privileges to perform a specific task.
  • separation of duties – for any given task, more than one individual needs to be involved.
  • defense in depth (layered security) – apply multiple dissimilar security defenses.
  • fail-safe – when a system experience a failure, it should fail to a safe state; all the attributes associated with the system security (confidentiality, integrity, availability) should be appropriately maintained.
  • economy of mechanism – keep the design of the system simple and less complex; reduce the number of dependencies and/or services that the system needs in order to operate.
  • complete mediation – checking permission each time subject requests access to objects.
  • open design – design is not a secret, implementation of safeguard is. (ex: cryptography algorithms are open but the keys used are secret)
  • least common mechanism – minimize the amount of mechanism common to more than one user and depended on by all users. Every shared mechanism (especially one involving shared variables) represents a potential information path between users and must be designed with great care to be sure it does not unintentionally compromise security.
  • psychological acceptability – accessibility to resources should not be inhibited by security mechanisms. If security mechanisms hinder the usability or accessibility of resources, then users may opt to turn off those mechanisms.
  • weakest link – attackers are more likely to attack a weak spot in a software system than to penetrate a heavily fortified component.
  • leverage existing components – component reuse have many advantages, including the increasing of efficiency and security. From the security point of view the component reuse is reducing the attack surface.
  • single point of failure – a system design should not be susceptible to a single point of failure.

Security Models

Access Control Models

Access controls define what actions a subject can perform on specific objects.

  • Bell-LaPadula confidentiality model – It is focused on maintaining the confidentiality of objects. Bell-LaPadula operates by observing two rules: the Simple Security Property and the * Security Property.
    • The Simple security property states that there is “no read up:” a subject at a specific classification level cannot read an object at a higher classification level.
    • The * Security Property is “no write down:”a subject at a higher classification level cannot write to a lower classification level.
  • Take-Grant  – systems specify the rights that a subject can transfer to a from another subject or object. The model is based on representation of the controls in forms of directed graphs with the vertices being the subjects and the objects. The edges between them represent the right between the subject and objects. The representation of rights takes the form of {t (take), g (grant), r (read), w (write)}.
  • Role-based Access control – users are assign a set of roles they may perform. The roles are associated to the access permissions necessary to perform the tasks.
  • MAC (Mandatory Access Control) Model – in MAC systems the owner or subject cannot determine whether access is to be granted to another subject; it is the job of the operating system to decide.
  • DAC (Discretionary Access Control) Model – in DAC systems the owner of an object can decide which other subjects may have access to the object what specific access they may have.

Integrity Models

  • Biba integrity model  – (sometimes referred as Bell-LaPadula upside down) was the first formal integrity model.  Biba is the model of choice when integrity protection is vital. The Biba model has two primary rules: the Simple Integrity Axiom and the * Integrity Axiom. 
    • The Simple Integrity Axiom is “no read down:”a subject at a specific classification level cannot read data at a lower classification. This protects integrity by preventing bad information from moving up from lower integrity levels.
    • The * Integrity Axiom is “no write up:”a subject at a specific classification level cannot write to data at a higher classification. This protects integrity by preventing bad information from moving up to higher integrity levels.
  • Clark-Wilson  –  (this is an informal model) that protects integrity by requiring subjects to access objects via programs. Because the programs have specific limitations to what they can and cannot do to objects, Clark-Wilson effectively limits the capabilities of the subject.Clark-Wilson uses two primary concepts to ensure that security policy is enforced; well-formed transactions and Separation of Duties.

Information Flow Models

Information in a system must be protected when at rest, in transit and in use.

  • The Chinese Wall model – designed to avoid conflicts of interest by prohibiting one person, such as a consultant, from accessing multiple conflict of interest categories (CoIs). The Chinese Wall model requires that CoIs be identified so that once a consultant gains access to one CoI, they cannot read or write to an opposing CoI.

 

Risk Management

Vocabulary

  • risk – possibility of suffering harm or loss
  • residual risk – risk that remains after a control was added to mitigate the initial risk.
  • total risk – the sum of all risks associated with an asset.
  • asset – resource an organization needs to conduct his business.
  • threat – circumstance or event with the potential to cause harm to an asset.
  • vulnerability – any characteristic if an asset that can be exploited by a threat to cause harm.
  • attack – attempting to use a vulnerability.
  • impact – loss resulting when a threat exploits a vulnerability.
  • mitigate – action taken to reduce the likelihood of a threat.
  • control – measure taken to detect, prevent or mitigate the risk associated with a threat.
  • risk assessment – process of identifying risks and mitigating actions.
  • qualitative risk assessment – subjectively determining the impact of an event that effects assets.
  • quantitative risk assessment –  objectively determining the impact of an event that effects assets.
  • single loss expectation (SLE) – linked to the quantitative risk assessment, it represents the monetary loss or impact of each occurrence of a threat.
    • SLE = asset value * exposure factor
  • exposure factor – linked to the quantitative risk assessment, is a measure of the magnitude of a loss.
  • annualized rate of occurrence (ARO) – linked to the quantitative risk assessment, is the frequency with an event is expected to occur on an annualized basis.
    • ARO = number of events / number of years
  • annualized loss of expectancy (ALE) – linked to the quantitative risk assessment, it represents how much an event is expected to cost per year.
    • ALE = SLE * ARO

Types of risks:

  • Business Risks:
    • fraud
    • regulatory
    • treasury management
    • revenue management
    • contract management
  • Technology Risks:
    • security
    • privacy
    • change management

Types of controls

Controls can be classified on types of actions they perform. Three classes of controls exist:

  • administrative
  • technical
  • physical

For each of these classes, there are four types of controls:

  • preventive (deterrent) – used to prevent the vulnerability
  • detective – used to detect the presence of an attack.
  • corrective (recovery) – correct a system after a vulnerability is exploited and an impact has occurred; backups are  a common form of corrective controls.
  • compensation – designed to act when a primary set of controls has failed.

Risk management models

General risk management model

The steps contained in a general risk management model:

  1. Asset identification – identify and clarify all the assets, systems and processes that need to be protected.
  2. Threat assessment – identify the threats and vulnerabilities associated with each asset.
  3. Impact determination and qualification
  4. Control design and evaluation – determine which controls to put in place to mitigate the risks.
  5. Residual risk management – evaluate residual risks to identify where additional controls are needed.

Risk management model proposed by Software Engineering Institute

SEI model steps :

  1. Identity – enumerate potential risks.
  2. Analyze – convert the risk data gather into information that can be used to make decisions.
  3. Plan – decide the actions to take to mitigate them.
  4. Track – monitor the risks and mitigations plans.
  5. Control – make corrections for deviations from the risk mitigation plan.

Security Policies and Regulations

One of the most difficult aspects of prosecution of computer crimes is attribution. Meeting the burden of proof requirement in criminal proceedings, beyond a reasonable doubt, can be difficult given an attacker can often spoof the source of the crime or can leverage different systems under someone else’s control.

Intellectual property

Intellectual property is protected by the U.S law under one of four classifications:

  • patents – Patents provide a monopoly to the patent holder on the right to use, make, or sell an invention for a period of time in exchange for the patent holder’s making the invention public.
  • trademarks – Trademarks are associated with marketing: the purpose is to allow for the creation of a brand that distinguishes the source of products or services.
  • copyrights – represents a type of intellectual property that protects the form of expression in artistic, musical, or literary works, and is typically denoted by the circle c symbol. Software is typically covered by copyright as if it were a literary work. Two important limitations on the exclusivity of the copyright holder’s monopoly exist: the doctrines of first sale and fair use. The first sale doctrine allows a legitimate purchaser of copyrighted material to sell it to another person. If the purchasers of a CD later decide that they no longer cared to own the CD, the first sale doctrine gives them the legal right to sell the copyrighted material even though they are not the copyright holders.
  • trade secrets – business-proprietary information that is important to an organization’s ability to compete. Software source code or firmware code are examples of computer-related objects that an organization may protect as trade secrets.

Privacy and data protection laws

Privacy and data protection laws are enacted to protect information collected and maintained on individuals from unauthorized disclosure or misuse.

Several important pieces of privacy and data protection legislation include :

  • U.S. Federal Privacy Act of 1974 – protects records and information maintained by U.S. government agencies about U.S. citizens and lawful permanent residents.
  •  U.S. Health Insurance Portability and Accountability Act (HIPAA) of 1996 – seeks to guard protected health information from unauthorized use or disclosure.
  • Payment Card Industry Data Security Standard (PCI-DSS) – the goal is to ensure better protection of card holder data through mandating security policy, security devices, control techniques and monitoring of systems and networks.
  • U.S. Gramm-Lech-Bliley Financial Services Modernization Act (GLBA) – requires financial institutions to protect the confidentiality and integrity of consumer financial information.
  • U.S. Sarbanes-Oxley Act of 2002 (SOX) – the primary goal of SOX is to ensure adequate financial disclosure and financial auditor independence.

Secure Software Architecture – Security Frameworks

  • COBIT (Control Objectives for Information and Related Technology)– assist management in bringing the gap between control requirements, technological issues and business risks.
  • COSO (Committee of Sponsoring Organizations of the Treadway Commission) – COSO has established a Enterprise Risk Management -Integrated Framework against which companies and organizations may assess their control systems.
  • ITIL (Information Technology Infrastructure Library) – describes a set of practices focusing on aligning IT services with business needs.
  • SABSA (Sherwood Applied Business Security Architecture) – framework and methodology for developing risk-driven enterprise information security architecture.
  • CMMI (Capability Maturity Model Integration) – process metric model that rates the process maturity of an organization on a 1 to 5 scale.
  • OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation) – suite of tools, techniques and methods for risk-based information security assessment.

 

Software Development Methodologies

Secure Development Lifecycle Components

  • software team awareness and education – all team members should have appropriate training. The key element of team awareness and education is to ensure that all the members are properly equipped with the correct knowledge.
  • gates and security requirements – the term gates it signifies a condition that one must pass through. To pass the security gate a review of the appropriate security requirements is conducted.
  • threat modeling – design technique used to communicate information associated with a threat throughout the development team (for more infos’ you could check my other ticket : threat modeling for mere mortals).
  • fuzzing – a test technique where the tester applies a series of inputs to an interface in an automated fashion and examines the output for undesired behaviors.
  • security reviews – process to ensure that the security-related steps are being carried out and not being short-circuited.

Software Development Models

  • waterfall model – is a linear application development model that uses rigid phases; when one phase ends, the next begins.
  • spiral model – repeats steps of a project, starting with modest goals, and expanding outwards in ever wider spirals (called rounds). Each round of the spiral constitutes a project, and each round may follow traditional software development methodology such as Modified Waterfall. A risk analysis is performed each round.
  • prototype model – working model of software with some limited functionality. Prototyping is used to allow the users evaluate developer proposals and try them out before implementation.
  • agile model
    • Scrum  – contain small teams of developers, called the Scrum Team. They are supported by a Scrum Master, a senior member of the organization who acts like a coach for the team. Finally, the Product Owner is the voice of the business unit.
    • Extreme Programming (XP) – method that uses pairs of programmers who work off a detailed specification.

Microsoft Security Development Lifecycle

SDL is software development process designed ti enable development teams to build more secure software and address security compliance requirements.

SDC is build around the following three elements:

  • (security) by design – the security thinking is incorporated as part of design process.
  • (security) by default – the default configuration of the software is by design as secure as possible.
  • (security) in deployment – security and privacy elements are properly understood and managed through the deployment process.

SDL components:

  • training   security training for all personnel, targeted to their responsibility associated with the development effort.
  • requirements
    • establishment of the security and privacy requirements for the software.
    • creation of quality gates ans bug bars. Defining minimum acceptable levels of security and privacy quality at the start helps a team understand risks associated with security issues, identify and fix security bugs during development, and apply the standards throughout the entire project.Setting a meaningful bug bar involves clearly defining the severity thresholds of security vulnerabilities (for example, no known vulnerabilities in the application with a “critical” or “important” rating at time of release) and never relaxing it once it’s been set.
    • development of security and privacy risk assessment. Examining software design based on costs and regulatory requirements helps a team identify which portions of a project will require threat modeling and security design reviews before release and determine the Privacy Impact Rating of a feature, product, or service.
  • design – establish design requirements, perform attack/surface analysis/reduction and use threat modeling.
  • implementation – application of secure coding practices and the use of static program checkers to find common errors.
  • verification – perform dynamic analysis (tools that monitor application behavior for memory corruption, user privilege issues, and other critical security problems), fuzz testing and conduct attack surface review.
  • release – conduct final security review and create an incident response plan.
  • response – execute incident response plan.