Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

(My) CSSLP Notes: Secure Software Concepts

DZone's Guide to

(My) CSSLP Notes: Secure Software Concepts

None of use can remember everything. So, here's a nice outline of all the core software security concepts you'll need, in one convenient post.

· Security Zone
Free Resource

Discover how to protect your applications from known and unknown vulnerabilities.

Basics

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 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 experiences 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 a subject requests access to objects.
  • Open design – design is not a secret, the implementation of the safeguard is (ex: cryptography algorithms are open but the keys used are secret).
  • Least common mechanism – minimize the amount of mechanisms 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 has many advantages, including the increase of efficiency and security. From the security point of view, component reuse reduces 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 or from another subject or object. The model is based on the 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 assigned a set of roles they may perform. The roles are associated with 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, and what specific kind of access they may have.

Integrity Models

  • Biba Integrity Model  – sometimes referred as Bell-LaPadula upside down, this 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 business.
  • Threat – circumstance or event with the potential to cause harm to an asset.
  • Vulnerability – any characteristic of 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 – a 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 affects assets.
  • Quantitative risk assessment –  objectively determining the impact of an event that affects 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 into the 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 gathered 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 law 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 care 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 against unauthorized use or disclosure.
  • Payment Card Industry Data Security Standard (PCI-DSS) – the goal is to ensure better protection of cardholder 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 bridging the gap between control requirements, technological issues, and business risks.
  • COSO (Committee of Sponsoring Organizations of the Treadway Commission) – COSO has established an 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 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 information, you could check my other article: 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 to enable development teams to build more secure software and address security compliance requirements.

SDC is built 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 and bug bars. Defining minimum acceptable levels of security and privacy quality at the start helps a team understand risks associated with security issues, to 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 the 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 a final security review and create an incident response plan.
  • Response – execute incident response plan.

Find out how Waratek’s award-winning virtualization platform can improve your web application security, development and operations without false positives, code changes or slowing your application.

Topics:
security ,security gateway ,software security

Published at DZone with permission of Adrian CITU, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}