Security: Information Security, threats, risks

Vulnerability is software, hardware, procedural, or human weakness that may provide an attacker the open door he is looking for to enter a computer or network and have unauthorized access to resources within the environment. A vulnerability characterizes the absence or weakness of a safeguard that could be exploited.

Threat is any potential danger to information or systems. The threat is that someone, or something, will identify a specific vulnerability and use it against the company or individual. The entity that takes advantage of a vulnerability is referred to as a threat agent.

Risk is the likelihood of a threat agent taking advantage of a vulnerability and the corresponding business impact. If a firewall has several ports open, there is a higher likelihood that an intruder will use one to access the network in an unauthorized method.

An exposure is an instance of being exposed to losses from a threat agent.

A countermeasure, or safeguard, is put into place to mitigate the potential risk. A countermeasure may be a software configuration, a hardware device, or a procedure that eliminates a vulnerability or that reduces the likelihood a threat agent will be able to exploit a vulnerability.

Typical Threat Agents:

• Accidental discovery
• Automated malware
• curious attacker
• Script kiddie
• motivated attacker ( or disgruntled employee)
• Organized crime.

Security model

Security Principles

• Minimize attack surface
• secure defaults
• principle of least privilege
• defense in depth
• Fail securely
• External systems are insecure.
• separation of duties
• It ensures no single person has total control over an activity or task.
• Split knowledge and dual control are two aspects of separation of duties.
• Do not trust security through obscurity
• simplicity
• fix security issues correctly

Security planning

Has various layers, but it also has different types of goals to accomplish in different time frames.

• Strategic planning is the plans that fall in line with the business and information technology goals.
• Tactical planning refers to the initiatives and other support that must be implemented to reach the broader goals that have been put forth by the strategic planning
• operational planning deals with very specific plans, their deadlines, and goals.

This approach to planning is called the planning horizon.

Security Frameworks

The Control Objectives for Information and related Technology (CobiT) was created by the Information Systems Audit and Control Association (ISACA) to provide specific guidance for creating and assessing IT controls. It is a framework and set of best practices developed by the Information Systems Audit and Control Association (ISACA) and the IT Governance Institute (ITGI). It defines goals for the controls that should be used to properly manage IT and to ensure that IT maps to business needs. 

CobiT is broken down into four domains(34 IT processes, ranging from strategic planning to implementation, production support and monitoring):

• Plan and Organize, 
• Acquire and Implement, 
• Deliver and Support, and 
• Monitor and Evaluate.

CobiT

CobiT is a framework that defines goals for the controls that should be used to properly manage IT and to ensure that IT maps to business needs.

Derived from the COSO framework, developed by the Committee of Sponsoring Organizations (COSO) of the Treadway Commission in 1985 to deal with fraudulent financial activities and reporting. The COSO framework is made up of the following components:

• Control environment

 - Management's philosophy and operating style

 - Company culture as it pertains to ethics and fraud

• Risk assessment

 - Establishment of risk objectives

 - Ability to manage internal and external change

• Control activities

 - Policies, procedures, and practices put in place to mitigate risk

• Information and communication

 - Structure that ensures that the right people get the right information at the right time

• Monitoring

 - Detecting and responding to control deficiencies

COSO is a Model for corporate governance and CobiT is a model for IT governance. COSO deals more at the strategic level, while CobiT focuses more at the operational level. You can think of CobiT as a way to meet many of the COSO objectives, but only from the IT perspective. COSO deals with non-IT items also, as in company culture, financial accounting principles, board of director responsibility, and internal communication structures. COSO was formed to provide sponsorship for the National Commission on Fraudulent Financial Reporting, an organization that studies deceptive financial reports and what elements lead to them.

COBIT information security topics

• Security Policy

    A policy would typically address a specific topic such as acceptable use of company e-mail, or wireless communications.

• Security Standards

For example, the Benchmark provided by the Center for Internet Security (CIS). This benchmark provides specific guidance for configuring security on a Windows 2000 server.

• Access and Authentication

In addition to AA,   Includes user and account mgmt.

• Network Security

 firewalls, intrusion detection systems (IDS), encryption, certificates.
 - antivirus is mandatory.
 - use ethical hacking or penetration testing to test systems.

• Monitoring

invalid logins, port scans, invalid authorization requests,  use analysis tools if appt.

• Segregation of Duties

• Physical Security

The Information Technology Governance Institute (ITGI) is a group created to assist corporations with governing their IT and ensuring IT efficiently supports business mission and goals. ITGI has used COSO and COBIT to create a set of specific IT control objectives for SOX.

Security Standards

Guidelines are recommendations and general approaches that provide advice and flexibility. 

There are standards and industry best practices, which provide the guidance and recipe for how to set up and implement a full security program.

A standard specifies how hardware and software are to be used. Standards are compulsory. 

The most common standard used to be ISO 17799, which was derived from the British Standard 7799

(BS7799). It is an internationally recognized Information Security Management (ISM) Standard that provides high-level conceptual recommendations on enterprise security. The British Standard actually has two parts:

• - BS7799 Part 1: outlines control objectives and a range of controls to meet those objectives; and 
• - BS7799 Part 2, which outlines how a security program can be set up and maintained. 

BS7799 Part 2 also served as a baseline that organizations could be certified against. To become certified against the ISO 17799, an authorized third party would evaluate the organization against the requirements in ISO 17799 Part 2. The organization could be certified against all or just a portion of ISO 17799 Part 2.

ISO/IEC 27000

ISO 9000 series comprises many standards that deal with quality control for business processes. A new series, ISO/IEC 27000, is used for assurance and security standards. ISO has overhauled the 17799 standards to correspond with their current numbering format. Following are the ISO/IEC series that are used as blueprints for organizations to follow when developing their security program:

• ISO/IEC 27001 Based on British Standard BS7799 Part 2, which is establishment, implementation, control, and improvement of the Information Security Management System
• It is the standard for the establishment, implementation, control, and improvement of the Information Security Management System.
• ISO/IEC 27002 Code of practice providing good practice advice on ISMS (previously known as ISO 17799 part 1), itself based on British Standard BS 7799 Part 1
• It is a comprehensive set of controls comprising best practices in information security and provides guidelines on how to set up and maintain security programs.
• ISO/IEC 27004 A standard for information security management measurements
• ISO/IEC 27005 Designed to assist the satisfactory implementation of information security based on a risk management approach
• ISO/IEC 27006 A guide to the certification/registration process
• ISO/IEC 27799 A guide to illustrate how to protect personal health information

The ISO/IEC 27002 (formerly ISO 17799) domains are as follows:

• Information security policy for the organization
• Creation of information security infrastructure
• Asset classification and control
• Personnel security
• Physical and environmental security
• Communications and operations management
• Access control
• System development and maintenance
• Business continuity management
• Compliance

ITIL 

Where CobiT defines IT goals, ITIL provides the steps at the process level on how to achieve those goals. Although ITIL has a component that deals with security, its focus is more toward internal service level agreements between the IT department and the "customers" it serves. The customers are usually internal departments.

Security Governance

Security governance is all of the tools, personnel, and business processes necessary to ensure that the security implemented meets the organization's specific needs.

Governance is the set of responsibilities and practices exercised by the board and executive management with the goal of providing strategic direction, ensuring that objectives are achieved, ascertaining that risks are managed appropriately, and verifying that the enterprise's resources are used responsibly.

Security Program Development

It is important to understand that a security program has a life cycle that is always continuing, because it should be constantly evaluated and improved upon.  The security program should be integrated with current business objectives and goals.

The life cycle of any process can be described in different ways.

1.     Plan and Organize

• Establish management commitment.
• Establish oversight steering committee.
• Assess business drivers.
• Carry out a threat profile on the organization.
• Carry out a risk assessment.
• Develop security architectures at an organizational, application, network, and component level.
• Identify solutions per architecture level.
• Obtain management approval to move forward.

2.     Implement

• Assign roles and responsibilities.
•  Develop and implement security policies, procedures, standards, baselines, and guidelines.
•  Identify sensitive data at rest and in transit.
•  Implement the following blueprints:
•  Asset identification and management
•  Risk management
•  Vulnerability management
•  Compliance
•  Identity management and access control
•  Change control
•  Software development life cycle
•  Business continuity planning
•  Awareness and training
•  Physical security
•  Incident response
•  Implement solutions (administrative, technical, physical) per blueprint.
•  Develop auditing and monitoring solutions per blueprint.
•  Establish goals, service level agreements (SLAs), and metrics per blueprint.

3.     Operate and Maintain

•  Follow procedures to ensure all baselines are met
•  Carry out internal and external audits.
•  Carry out tasks outlined per blueprint.
•  Manage service level agreements

4.     Monitor and Evaluate

•  Review logs, audit results, collected metric values, and SLAs per blueprint.
•  Assess goal accomplishments
• quarterly meetings
•  improvement steps and integrate into the Plan and Organize phase.

Information risk management (IRM) 

IRM is the process of identifying, assessing, and reducing risk to an acceptable level and implementing the right mechanisms to maintain that level of risk.

Proper risk management requires a strong commitment from senior management, a documented process that supports the organization's mission, an IRM policy, and a delegated IRM team.

The risk management team should include individuals from different departments within the organization, not just technical personnel.

Threats must be identified, classified by category, and evaluated to calculate their damage potential to the company. Real risk is hard to measure, but prioritizing the potential risks in order of which ones must be addressed first is possible.

Risk analysis

which is really a tool for risk management, is a method of identifying vulnerabilities and threats and assessing the possible impacts to determine where to implement security safeguards. Risk analysis is used to ensure that security is cost-effective, relevant, timely, and responsive to threats.

Identifying Threats

Illogical processing and cascading errors would mean invalid results are passed

on to another process. Risks have loss potential, meaning what the company would lose if a threat agent were actually to exploit a vulnerability. Must look at delayed loss when assessing the damages that can occur

Methodologies for Risk Assessment

• NIST SP 800-30 and 800-66 are methodologies that can be used by the general public, but the initial creation of 800-66 was designed to be implemented in the healthcare field and other regulated industries. While 800-66 was designed to be used by HIPAA clients, it can also be readily adopted and used by other regulated industries. The NIST approach is specific to IT threats and is commonly used by security consultants, security officers and internal IT departments, and focuses mainly on computer systems

·        FRAP

Which stands for Facilitated Risk Analysis Process. It is designed to explore a qualitative risk assessment process in a manner that allows for tests to be conducted on different aspects and variations of the methodology. This will allow, through the use of a prescreening process, users to determine the areas that really demand and need risk analysis within an organization. 

• OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) was created by Carnegie Mellon University's Software Engineering Institute. It is a methodology that is intended to be used in situations where people manage and direct the risk evaluation for information security within their company. 

         The limitations of OCTAVE are:

1. OCTAVE is incompatible with AS/NZS 4360, as it mandates Likelihood = 1 (i.e., It assumes a threat will always occur)
2. Consisting of 18 volumes, OCTAVE is large and complex, with many worksheets and practices to implement.
3. It does not provide a list of “out of the box” practices for assessing and mitigating web application security risks.
4. Because of these issues and not considering, OWASP does not anticipate that OCTAVE will be used at large by application designers or developers

• AS/NZS 4360: While both the NIST and OCTAVE methodologies focus on IT threats and information security risks, AS/NZS 4360 takes a much broader approach to risk management. This methodology can be used to understand a company's financial, capital, human safety, and business decisions risks. Although it can be used to analyze security risks, it was not created specifically for this purpose.

o   The advantages of AS/NZS 4360:

• AS/NZS 4360 works well as a risk management methodology for organizations requiring Sarbanes-Oxley compliance.
• AS/NZS 4360 works well for organizations that prefer to manage risks in a traditional way, such as just using likelihood and consequence to determine an overall risk.
• AS/NZS 4360 is familiar to most risk managers worldwide, and your organization may already have implemented an AS/NZS 4360 compatible approach.
• You are an Australian organization, and may be required to use it if you are audited on a regular basis, or to justify why you aren’t using it. Luckily, the STRIDE/DREAD model discussed earlier is AS/NZS 4360 compatible.
• The limitations of AS/NZS 4360:
• The AS/NZS 4360 approach works best for business or systemic risks than for technical risks.
• AS/NZS 4360 does not define the methodology to perform a structured threat risk modeling exercise.
• As AS/NZS 4360 is a generic framework for managing risk, it does not provide any structured method to enumerate web application security risks.

              Although AS/NZS 4360 may be used to rank risks for security reviews, the lack of structured methods of enumerating threats for web applications makes it less desirable than other methodologies described earlier.

• CVSS: The US Department of Homeland Security (DHS) established the NIAC Vulnerability Disclosure Working Group, which incorporates input from Cisco Systems, Symantec, ISS, Qualys, Microsoft, CERT/CC, and eBay. One of the group’s outputs is the Common Vulnerability Scoring System (CVSS).

• Failure Modes and Effect Analysis (FMEA) is a method for determining functions, identifying functional failures, and assessing the causes of failure and their failure effects through a structured process. While FMEA is most useful as a survey method to identify major failure modes in a given system, the method is not as useful in discovering complex failure modes that may be involved in multiple systems or subsystems. 
• A fault tree analysis usually proves to be a more useful approach to identifying failures that can take place within more complex environments and systems.

Quantitative risk analysis 

attempts to assign real and meaningful numbers to all elements of the risk analysis process. These elements may include safeguard costs, asset value, business impact, threat frequency, safeguard effectiveness, exploit probabilities, and so on. Purely quantitative risk analysis is not possible because the method attempts to quantify qualitative items, and there are always uncertainties in quantitative values

Note Quantitative analysis uses risk calculations that attempt to predict the level of monetary losses and the probability for each type of threat. Qualitative analysis does not use calculations. Instead, it is more opinion-and scenario based.

The Single loss expectancy is a dollar amount that is assigned to a single event that represents the company's potential loss amount if a specific threat were to take place:

•             SLE = asset value × exposure factor (EF)

exposure factor (EF) represents the percentage of loss a realized threat could have on a certain asset

• annualized loss expectancy (ALE) = SLE × annualized rate of occurrence (ARO)

annualized rate of occurrence (ARO) is the value that represents the estimated frequency of a specific threat taking place within a one-year timeframe.

Qualitative Risk Analysis

Does not assign numbers and monetary values to components and

losses. Instead, qualitative methods walk through different scenarios of risk possibilities and rank the seriousness of the threats and the validity of the different possible countermeasures based on opinions.

A qualitative rating would be expressed in high, medium, or low, or on a scale of 1 to 5 or 1 to 10. A quantitative result would be expressed in dollar amounts and percentages. 

     In risk analysis, uncertainty refers to the degree to which you lack confidence in an estimate.

The Delphi technique is a group decision method used to ensure that each member gives an honest opinion of what he or she thinks the result of a particular threat will be.

Advantages of Qualitative

Requires no calculations 

Provides general areas and indications of risk 

Provides the opinions of the individuals who know the processes best.

Advantages of Quantitative.

Uses independently verifiable and objective metrics

Is easier to automate and evaluate

Very less guesswork 

Provides credible cost/benefit analysis 

Used in risk management performance tracking 

A security countermeasure, sometimes called a safeguard, must make good business sense, meaning it is cost-effective (its benefit outweighs its cost). This requires another type of analysis: a cost/benefit analysis. A commonly used cost/benefit calculation for a given safeguard is

(ALE before implementing safeguard) - (ALE after implementing safeguard) - (annual cost of safeguard) = value of safeguard to the company

Total Risk vs. Residual Risk

• threats × vulnerability × asset value = total risk
• (threats × vulnerability × asset value) × controls gap = residual risk

Handling Risk

Project sizing, which means to understand and document the scope of the project, must be done before a risk analysis is performed.

The main goals of risk analysis are the following: identify assets and assign values to them, identify vulnerabilities and threats, quantify the impact of potential threats, and provide an economic balance between the impact of the risk and the cost of the safeguards.

Steps of a Risk Analysis

• Step 1: Assign Value to Assets
• When determining the value of information, the following issues must be considered: the cost to acquire and develop data; the cost to maintain and protect data; the value of the data to owners, users, and adversaries; the cost of replacement if the data is lost; the price others are willing to pay for the data; lost opportunities; and the usefulness of the data
• Step 2: Estimate Potential Loss Per Threat (including SLE)
• Step 3: Perform a Threat Analysis
• Step 4: Derive the Overall Annual Loss Potential Per Threat
• Step 5: Reduce, Transfer, Avoid, or Accept the Risk

3 Main steps for Risk Analysis:

• Asset and Information value assignment
• Risk Analysis and assessment
• countermeasure selection and implementation

Risk Management could take the input from Planning and collecting information and defining the recommendations. It can then handle the risk as:

• Risk transfer
• Risk Avoidance
• Risk Mitigation
• Risk Acceptance

Automated risk analysis tools reduce the amount of manual work involved in the analysis. They can be used to estimate future expected losses and calculate the benefits of different security measures. 

Security Policy

A security policy is a statement by management dictating the role security plays in the organization. A security policy can be an organizational policy, an issue-specific policy, or a system-specific policy.

Due diligence is an understanding of the current threats and risks, and due care is implementing countermeasures to provide protection from those threats. If a company does not practice due care and due diligence pertaining to the security of its assets, it can be legally charged with negligence and held accountable for any ramifications of that negligence. 

Other regulations also call out requirements of boards of directors, as in the Gramm-Leach-Bliley Act (GLBA). But SOX is a regulation that holds the members of the board personally responsible, thus they can each be fined or go to jail.

Principles of Federal Prosecution of Business Organizations

The Department of Justice provides the following guidelines for attorneys when attempting to prosecute corporate wrongdoings:

Do the corporation's directors exercise independent review over proposed corporate actions rather than unquestioningly ratifying officers' recommendations; are the directors provided with information sufficient to enable the exercise of independent judgment; are internal audit functions conducted at a level sufficient to ensure their independence and accuracy; and have the directors established an information and reporting system in the organization reasonably designed to provide management and the board of directors with timely and accurate information sufficient to allow them to reach an informed decision regarding the organization's compliance with the law.

International Requirements

If the organization is exchanging data with European entities, it may need to adhere to the safe harbor requirements. outlines how any entity that is going to move privacy data to and from Europe must go about protecting it.

Global organizations that move data across other country boundaries must also be aware of and follow the

Organisation for Economic Co-operation and Development (OECD) Guidelines and transborder information flow rules.

Summary: Security management 

A security program should address issues from a strategic, tactical, and operational view.

A key element during the initial security planning process is to define reporting relationships.

Security management embodies the administrative and procedural activities necessary to support and protect information and company assets throughout the enterprise. 

• Management must define the scope and purpose of security management, provide support, appoint a security team, delegate responsibility, and review the team's findings.

• It includes development and enforcement of security policies and their supporting mechanisms: procedures, standards, baselines, and guidelines. 

• It encompasses risk management, security awareness training, and proper countermeasure selection and implementation. 

• Personnel (hiring, terminating, training, and management structure) and operational (job rotation and separation of duties) activities must also be conducted properly to ensure a secure environment. 

• Management must understand the legal and ethical responsibilities it is required to respect and uphold.

• Security management should work from the top down (from senior management down to the staff).

Summary

• The objectives of security are to provide availability, integrity, and confidentiality protection to data and resources.

• Security components can be technical (firewalls, encryption, and access control lists) or nontechnical (security policy, procedures, and compliance enforcement).

• Asset identification should include tangible assets (facilities and hardware) and intangible assets (corporate data and reputation).

• Assurance is a degree of confidence that a certain security level is being provided.

• Procedures are detailed step-by-step actions that should be followed to achieve a certain task.

• A baseline is a minimum level of security. 

• Job rotation is a control to detect fraud.

• Mandatory vacations are a control type that can help detect fraudulent activities. 

• Data is classified to assign priorities to data and ensure the appropriate level of protection is provided.

• Data owners specify the classification of data.

• Security has functional requirements, which define the expected behavior from a product or system, and assurance requirements, which establish confidence in the implemented products or systems overall.

• Safeguards should default to least privilege, and have fail-safe defaults and override capabilities.

• Safeguards should be imposed uniformly so everyone has the same restrictions and functionality.

• The data custodian (information custodian) is responsible for maintaining and protecting data.

• A security analyst works at a strategic level and helps develop policies, standards, and guidelines, and also sets various baselines.

• Application owners are responsible for dictating who can and cannot access their applications, as well as the level of protection these applications provide for the data they process and for the company.

Appendix A: Microsoft Threat Modelling

Should fit alongside the "methodologies for Risk assessment" above.

STRIDE

STRIDE is a classification scheme for characterizing known threats according to the kinds of exploit that are used (or motivation of the attacker). 

Spoofing Identity “Identity spoofing” is a key risk for applications that have many users but provide a single execution context at the application and database level. 

Tampering with Data Users can potentially change data delivered to them, return it, and thereby potentially manipulate client-side validation, GET and POST results, cookies, HTTP headers, and so forth. 

Repudiation Users may dispute transactions if there is insufficient auditing or recordkeeping of their activity. 

Information Disclosure. Therefore, applications must include strong controls to prevent user ID tampering and abuse, particularly if they use a single context to run the entire application.

Denial of Service Application designers should be aware that their applications may be subject to a denial of service attack.

Elevation of Privilege If an application provides distinct user and administrative roles, then it is vital to ensure that the user cannot elevate his/her role to a higher privilege one.

DREAD

DREAD is a classification scheme for quantifying, comparing and prioritizing the amount of risk presented by each evaluated threat. T

Risk_DREAD = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) / 5

The calculation always produces a number between 0 and 10; the higher the number, the more serious the risk.

Threat Modeling Process

• Identify assets.
• Create an architecture overview.
• Identify what the application does.
• Create an architecture diagram.
• Identify the technologies.
• Decompose the application.
•  
• Identify trust boundaries.
• Identify data flow.
• Identify entry points.
• Identify privileged code.
• Document the security profile.
• Identify the threats(you can use STRIDE).
•  
• Identify network threats.
• Identity host threats.
• Identify application threats.
•  
• Using Attack Trees and Attack Patterns
• An attack tree is a way of collecting and documenting the potential attacks on your system in a structured and hierarchical manner. The tree structure gives you a descriptive breakdown of various attacks that the attacker uses to compromise the system.
• Attack Patterns
• Attack patterns are generic representations of commonly occurring attacks that can occur in a variety of different contexts. 
• Document the threats.
• Rate the threats.
• You can  use the DREAD model to rate the threats or use a quantitative approach.

For more details on alternative Threat modeling systems refer: 

http://softwarearchitectureandarchitects.blogspot.com/2012/04/threat-modelling.html

These are my notes collected from various sources and this is not claimed as original content.

Security: PCI Compliance

The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements designed to ensure that all companies that process, store or transmit credit card information maintain a secure environment.


Merchant levels as defined by Visa:
1: Any merchant processing over 6M Visa transactions per year
2: Any merchant processing 1M to 6M Visa transactions per year.
3: Any merchant processing 20,000 to 1M Visa e-commerce transactions per year.
4: Any merchant processing fewer than 20,000 Visa e-commerce transactions per year and other merchants processing up to 1M Visa transactions per year


Best Practices

·       Process transactions immediately online or hand off the processing to your bank

·       Do not store any CC numbers, ever. If they must be stored, you must follow the PCI guidelines to the letter. 

·       If you are using a shared host for your site, you cannot comply with the PCI guidelines. You must have your own infrastructure to comply with the PCI guidelines.

If you do end up storing CC numbers:

• Encrypt them.
• follow merchant agreement.
• for recurring payments, limit term to 1 year.

Other considerations:

• PCI only allows presentation of first six ( the BIN) or last four digits.
• Must nore store CCV etc.
• Must patch system within 1 month of a patch becoming available.
• reversals should be signed off by two distinct employees.

12 requirements of PCI-DSS if you are going to handle credit cards:

Build and maintain a secure network	Install and maintain a firewall configuration to protect data
	Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data	Protect stored data
	Encrypt transmission of cardholder data and sensitive information across public networks
Maintain a Vulnerability Management Program	Use and regularly update anti-virus software
	Develop and maintain secure systems and applications
Implement Strong Access Control Measures	Restrict access to data by business need-to-know
	Assign a unique ID to each person with computer access
	Restrict physical access to cardholder data
Regularly Monitor and Test Networks	Track and monitor all access to network resources and cardholder data
	Regularly test security systems and processes
Maintain an Information Security Policy	Maintain a policy that addresses information security

PCI Sections Addressing Application Security

• 3.1 Protect stored cardholder data 
• 3.2 Protect authentication data 
• 3.4 Protect Personal Account Numbers (PAN) data
• 4.1 Encrypt transmission of cardholder data across public networks
• 6.3 Develop and maintain secure applications
• 6.5 Develop web applications using secure coding 
• 6.6 Protect web applications against known attacks
• 8.1 Assign a unique ID to each person with computer access
• 10.1 Track and monitor all access to network resources and cardholder data
• 10.2 Implement automated audit trails
• 10.3 Record audit trail events
• 11.3 Regularly test security systems and processes
• 11.4 Use intrusion detection/ prevention systems

PA-DSS Summary

• Do not retain full magnetic stripe, card verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data
• Protect stored cardholder data 
• Provide secure authentication features
• Log payment application activity 
• Develop secure payment applications  
• Protect wireless transmissions  
• Test payment applications to address vulnerabilities  
• Facilitate secure network implementation  
• Cardholder data must never be stored on a server connected to the Internet  
• Facilitate secure remote access to payment application  
• Encrypt sensitive traffic over public networks  
• Encrypt all non-console administrative access  
• Maintain instructional documentation and training programs for customers, resellers, and integrators

Sarbanes Oxley (SOX)

SOX affects information security and the below are two specific sections of the act:

section 302: Corporate responsibility for financial reports

Section 302 states that the Chief Executive Officer (CEO) and Chief Financial  Officer (CFO) must personally certify that financial reports are accurate and complete. They must also assess and report on the effectiveness of internal controls around financial reporting.

section 404: Management assessment of internal controls

Section 404 states that a corporation must assess the effectiveness of its internal controls and report this assessment annually to the SEC. The assessment must
also be reviewed and judged by an outside auditing firm.

Public Company Accounting Oversight Board (PCAOB)

The role of PCOAB is to oversee and guide auditors as they assess a company’s compliance with SOX.
"Proposed Auditing Standards" provide more detailed guidance for assessing compliance with the intent of SOX. information technology (IT) general controls form the foundation for many other types of financial reporting controls and, therefore, must be assessed for SOX.

COSO & COBIT

For the purpose of internal control guidance, PCAOB has selected a control
framework created by the Committee of Sponsoring Organizations (COSO). The
COSO framework provides a structured and comprehensive set of guidelines for
creating and implementing internal controls.

The Information Technology Governance Institute (ITGI) is a group created to assist corporations with governing their IT and ensuring IT efficiently supports business mission and goals. ITGI has used COSO and COBIT to create a set of specific IT control objectives for SOX.

references

http://pcaobus.org

http://www.coso.org/default.htm
http://www.isaca.org/

Threat Modelling

Alternative Threat Modeling Systems

OWASP recognizes that the adoption of a Microsoft modeling process may be a controversial choice in some organizations. If STRIDE / DREAD is unacceptable due to unfounded prejudice, we recommend that every organization trial the various threat models against an existing application or design. This will allow the organization to determine which approach works best for them, and adopt the most appropriate threat modeling tools for their organization.

Performing threat modeling provides a far greater return than any control in this Guide. It is vital that threat modeling takes place.

Trike

Trike is a threat modeling framework with similarities to the Microsoft threat model process. However, Trike is differentiated by using a risk based approach with distinct implementation, threat and risk models, instead of using a mixed threat model (attacks, threats, and weaknesses) as represented by STRIDE / DREAD.

From the Trike paper, Trike aims to:

With assistance from the system stakeholders, ensure that the risk this system entails to each asset is acceptable to all stakeholders.

Be able to tell whether we have done this.

Communicate what we’ve done and its effects to the stakeholders.

Empower stakeholders to understand and reduce the risks to themselves and other stakeholders implied by their actions within their domains.

For more information, please review the “Further Reading” section below. The OWASP Guide 2.1 (due November 2005) will have more details on Trike.

AS/NZS 4360:2004 Risk Management

Australian Standard / New Zealand Standard AS/NZS 4360, first issued in 1999, is the world’s first formal standard for documenting and managing risk, and is still one of the few formal standards for managing risk. It was updated in 2004.

AS/NZS 4360’s approach is simple (it’s only 28 pages long) and flexible, and does not lock organizations into any particular method of risk management as long as the risk management fulfils the AS/NZS 4360 five steps. It provides several sets of risk tables and allows organizations to adopt their own.

The five major components of AS/NZS 4360’s iterative approach are:

Establish the context – establish what is to be risk treated, i.e. which assets / systems are important

Identify the risks – within the systems to be treated, what risks are apparent?

Analyze the risks – look at the risks and determine if there are any supporting controls

Evaluate the risks – determine the residual risk

Treat the risks – describe the method to treat the risks so that risks selected by the business can be mitigated.

AS/NZS 4360 assumes that risk will be managed by an operational risk style of group, and that the organization has adequate skills in house, and risk management groups to identify, analyze, and treat the risks.

Why you would use AS/NZS 4360:

AS/NZS 4360 works well as a risk management methodology for organizations requiring Sarbanes-Oxley compliance.

AS/NZS 4360 works well for organizations that prefer to manage risks in a traditional way, such as using just likelihood and consequence to determine an overall risk.

AS/NZS 4360 is familiar to most risk managers worldwide, and your organization may already have implemented an AS 4360 compatible approach

You are an Australian organization, and thus may be required to use it if you are audited externally on a regular basis, or justify why you are not using it. Luckily, the STRIDE / DREAD model referred to above is AS/NZS 4360 compatible.

Why you would not use AS/NZS 4360:

AS/NZS 4360’s approach works far better for business or systemic risks than technical risks

AS/NZS 4360 does not discuss methods to perform a structured threat risk modeling exercise

As AS/NZS 4360 is a generic framework for managing risk, it does not provide any structured method to enumerate web application security risks.

Although AS 4360 can be used to rank risks for security reviews, the lack of structured methods of enumerating threats for web applications makes it less desirable than other methods.

CVSS

The US Department of Homeland Security (DHS) established the NIAC Vulnerability Disclosure Working Group, which incorporates input from Cisco, Symantec, ISS, Qualys, Microsoft, CERT/CC, and eBay. One of the outputs of this group is the Common Vulnerability Scoring System (CVSS).

Why you would use CVSS:

You have just received notification from a security researcher or other source that your product has a vulnerability, and you wish to ensure that it has a trustworthy severity rating so as to alert your users to the appropriate level of action required when you release the patch

You are a security researcher, and have found several exploits for a program. You would like to use the CVSS ranking system to produce reliable risk rankings, to ensure that the ISV will take the exploits seriously as compared to their rating.

The use of CVSS is recommended for use by US government departments by the working group – it is unclear if this is policy at the time of writing.

Why you would not use CVSS:

CVSS does not find or reduce attack surface area (i.e. design flaws), nor help enumerate possible risks from any arbitrary piece of code as it is not designed for that purpose.

CVSS is more complex than STRIDE / DREAD, as it aims to model the risk of announced vulnerabilities as applied to released software.

CVSS risk ranking is complex – a spreadsheet is required to calculate the risks as the assumption behind CVSS is that a single risk has been announced, or a worm or Trojan has been released targeting a small number of attack vectors.

The overhead of calculating the CVSS risk ranking is quite high if applied to a thorough code review, which may have 250 or more threats to rank.

Octave

Octave is a heavyweight risk Methodology approach from CMU’s Software Engineering Institute in collaboration with CERT. OCTAVE is targeted not at technical risk, but organizational risk.

OCTAVE consists of two versions: OCTAVE – for large organizations and OCTAVE-S for small organizations, both of which have catalogs of practices, profiles, and worksheets to document the OCTAVE outcomes. OCTAVE is popular with many sites.

OCTAVE is useful when:

Implementing a culture of risk management and control within an organization

Documenting and measuring business risk

Documenting and measuring overall IT security risk, particularly as it relates to whole of company IT risk management

Documenting risks surrounding complete systems

When an organization is mature, does not have a working risk methodology in place, and requires a robust risk management framework to be put in place

The downsides of Octave are:

OCTAVE is incompatible with AS 4360, as it forces Likelihood=1 (i.e. a threat will always occur). This is also inappropriate for many organizations. OCTAVE-S has an optional inclusion of probability, but this is not part of OCTAVE.

Consisting of 18 volumes, OCTAVE is large and complex, with many worksheets and practices to implement

It does not provide a list of out of the box practices for web application security risks

OWASP does not expect OCTAVE to be used by designers or developers of applications, and thus it misses the raison d’être of threat modeling – which is to be used during all stages of development by all participants to reduce the risk of the application becoming vulnerable to attack.

Comparing threat modeling approaches

Here is how roughly the CVSS measures up to STRIDE / DREAD:

Metric	Attribute	Description	Closest STRIDE / DREAD
CVSS Base Metrics	Access vector	Local or remote access?	~ Exploitability
CVSS Base Metrics	Access complexity	How hard to reproduce the exploit	Reproducibility
CVSS Base Metrics	Authentication	Anonymous or authenticated?	~ Exploitability
CVSS Base Metrics	Confidentiality impact	Impact of confidentiality breach	Information Disclosure
CVSS Base Metrics	Integrity impact	Impact of integrity breach	Tampering
CVSS Base Metrics	Availability impact	Impact of system availability breach	Denial of Service
CVSS Base Metrics	Impact bias	Bias equal for CIA, or biased towards one or more of CIA?	No equivalent
CVSS Temporal	Exploitability	How easy is the breach to exploit?	Exploitability
CVSS Temporal	Remediation Level	Is a fix available?	No equivalent
CVSS Temporal	Report confidence	How reliable is the original report of the vulnerability?	No equivalent
CVSS Environmental	Collateral Damage	How bad is the damage if the threat were realized?	Damage potential
CVSS Environmental	Target Distribution	How many servers are affected if the threat were realized?	Affected users (not directly equivalent)

Alternatively, here is how STRIDE / DREAD map to CVSS:

STRIDE attribute	Description	Closest CVSS attribute
Spoofing identity	How can users obviate controls to become another user or act as another user?	No direct equivalent
Tampering with data	Can data be tampered with by an attacker to get the application to obviate security controls or take over the underlying systems (eg SQL injections)	Integrity
Repudiation	Can users reject transactions due to a lack of traceability within the application?	No direct equivalent
Information disclosure	Can authorization controls be obviated which would then lead to sensitive information being exposed which should not be?	Confidentiality
Denial of service	Can an attacker prevent authorized users from accessing the system?	Availability
Elevation of privilege	Can an anonymous attacker become a user, or an authenticated user act as an administrator or otherwise change to a more privileged role?	No direct equivalent

DREAD attribute	Description … if the threat is realized	Closest CVSS attribute
Damage potential	What damage may occur?	Collateral damage
Reproducibility	How easy is it for a potential attack to work?	~ Access complexity
Exploitability	What do you need (effort, expertise) to make the attack work?	Exploitability
Affected users	How many users would be affected by the attack?	Target distribution
Discoverability	How easy is for it attackers to discover the issue?	No direct equivalent

In general, CVSS is useful for released software and the number of realized vulnerabilities is small. CVSS should produce similar risk rankings regardless of reviewer, but many of the biases built into the overall risk calculation are subjective (i.e. local and remote or which aspect of the application is more important), and thus there may disagreement of the resulting risk ranking.

STRIDE/DREAD is useful to reduce attack surface area, improve design, and eliminate vulnerabilities before they are released. It can also be used by reviewers to rank and enumerate threats in a structured way, and produce similar risk rankings regardless of reviewer.

Conclusion

In the few previous pages, we have touched on the basic principles of web application security. Applications that honor the underlying intent of these principles will be more secure than their counterparts who are minimally compliant with specific controls mentioned later in this Guide. 

Apache CXF WS-Security, WS-policy links

I will come up with a brief post on how to achieve a basic "customizable" web service client that can understand ws-policy, ws-security to interact with a web server. Also it will cover how to customize the signature process etc.

A few links I find useful....
http://www.jroller.com/gmazza/entry/web_service_links_4_december

http://peterarockiaraj.wordpress.com/2009/09/04/developing-cxf-ws-security-with-signaturecertificates/

http://distributedsenses.blogspot.com/2008/09/configuring-cxf-for-web-service.html

Open source security( has useful posts on WS-Trust, STS, CXF etc):
http://coheigea.blogspot.com/

another one:
http://www.dankulp.com/blog/ 

Do we need software architects?

I have been thinking about finding the answer to this question ever since someone in my organization remarked, "aren't we all architects?" Not that I principally disagree with that statement, I don't think all of us can be effective architects. There is definitely a need to have specialized architects but what exactly are those needs?

Here are a few:

Without an architect, the project doesn't choose the best solution. 

Purely from a software development point of view, our main desire is to get things "working". The thought always is to have something working which we can later refine. While, this could  be a very good way to begin things, the problem is that we usually end up not wanting to change that initial implementation because it's too disruptive.

Since Architects (usually) don't have the immediate task to code, they come up with the best solution with the sole aim that the solution in itself is the best one and not necessarily because it can be coded by someone in the team. This sometimes does lead to a problem where the solution is too abstract or is simply not feasible but that can be discovered early by enforcing a tighter working relationship between the architect and the programmer.

Without an architect, the project lacks technical innovation. 

This is highly subjective but most architects I know are always up to date with the latest technology and have a desire to use that technology to solve the particular problem that the technology was intended to solve. Without an architect,:

• you either don't have someone that well informed 
• or you don't understand what the exact problem that can be solved by a particular technology 
• or you don't know how to use a particular technology to solve future problems.

Without an architect, the product/project is not future proof.

Architects bring a lot to the table but if a product/project doesn't have an architect(let's say has a lot of senior developers), then in most cases they wouldn't even know what they are missing. As per the team the development is going as per plan, they are progressing and the milestones are being met.

The problem is discovering (hopefully early) that the product/project

• is too rigid
• lacks adequate support for non-functional requirements
• progressively becomes harder to implement complex features
• discovering problems becomes very difficult. 

This probably summarizes my main points and being an architect, gives me some satisfaction....

SaaS (Software as a Service) and Multi-Tenancy

SaaS
SaaS can be defined as:
"software deployed as a hosted service and provided over the internet". 


   It is becoming an increasingly popular word, one that Software Vendors can ill-afford to ignore. It is opening up markets and segments that were previously inaccessible to vendors but it is also throwing up challenges like never before. 
    SaaS allows an application to scale to (theoretically) unlimited number of customers. It is typically achieved by on-demand horizontal and vertical scaling behind the scenes to provide a seamless experience to the user. 
    The practice of Application architecture has to adjust to account for SaaS and to Architect and Design applications for SaaS. Support for Multi-Tenancy is the approach some SaaS vendors follow to effectively address the SaaS challenges and this article will attempt to address the different aspects of Multi-Tenancy. So...


What is Multi-Tenancy
Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants).


Why Multi-tenancy?

• Great and Easy deployment. There is a single system to manage.
• Cost savings associated with less hardware(or Virtualized Hardware)
• Less software licenses to buy.

Multi-Tenancy Issues

• Security testing has to be extensively done.
• Expensive hardware to buy. Increased cost associated with big rack hardware.
• Not easy to convert an existing application/software to Multi-tenant. 
• Requires schema change to existing apps. 
• Pure Multi-tenancy requires applications and infrastructure to scale-up to address demand.
• Single point of failure issues. Which is the weakest link?
• Multiple tenant metadata is difficult to manage.
• Down time issues. What happens if the Database has to be brought down for maintenance?
• Access control. This could be managed and configured at diff customers and less control over issues surrounding this.
• Extensions to data model are tricky and sometimes impact all customers.
• What about architecture that relies on communication between components in SaaS world and ones behind the firewall ?

Muti-tenancy versus Virtualization
Virtualization to a limited extent seems to be a good alternative for Multi-tenancy. However there are drawbacks. Would virtualization be profitable if there were 1000 customers deployments? How would you deploy and manage such an environment? Also what would we do if the Customers are "on-demand"? Which means they may want to use the system for brief periods of time and then be gone for days/weeks/months. How do you keep a Virtualization solution profitable?


But this is not to say that it just can't be done profitably. There are solutions out there that are using Virtualization to achieve Multi-Tenancy especially If the customer deployments are in single or very low double digits.Virtualization might (better) provide the following benefits:

• Data Isolation.
• Security. Both at the PaaS layer and at the Virtualized layer.
• Performance ( one client can't directly impact the other's performance).

Designing for Multi-tenancy


Key points of Multi-Tenancy

• Flexibility
• Share-ability
• Maintainability
• Customizability

Architectural Constraints

• Maintain a single code base to ease deployments and upgrades.
• Share the data resources to have a consistent view of the Schema.
• Components must be customizable at every possible level.
• The Application Tier must be as stateless as possible to allow Scalability.

Trade offs

• Complexity versus Time to market. What do the customers want and when?
• Resource sharing vs Security/Availability. Who is my customer? Legal or SLA considerations?
• Customize-ability vs Maintainability. A myriad of customizable options. Which one was chosen when this issue occurred? How do we fix this without affecting everyone else?

Interfaces
Multi-Tenant applications should expose (and consume) standard based interfaces like

• REST
• WS-*

Configurable
The application has to be configurable. In a traditional MVC style of application, the following would have to be extensively configurable:
Model: Allow schema extensions.
Controller: Allow new business logic to be plugged in or existing ones to be enhanced. Allow modification/customization of security policy.
View: Allow look and feel changes, changing of display items, screen order, messages etc. This does assume that there is a metadata somewhere that allows the configuration options and allows the particular view to be "instantiated" based on the metadata.

Security

Security includes, secure the SaaS model as whole and has an application level security architecture and a Data level security architecture. Data level Security is addressed in the next section. Application level security could involve either storing all user accounts with the SaaS provider and/or federating authentication to  trusted STSs ( Security Token Services) or trusted Identity Providers.
The SaaS application can also provide configurable Identity Management modules that either do the authentication/authorization themselves or federate as noted above. If the Authentication is federated, then we need some kind of a mapping service to map roles from Trusted servers to the roles/policies defined in the SaaS application.

Multi-Tenant Data Architecture

• Separate Database 
• Easy to Maintain
• Customizable ( with probable issues later on)
• Secure
• Upgradable
• Higher costs
• Shared Database with separate Schema
• Easier to Maintain
• Customizable ( with probable issues later on)
• More Secure
• Upgradable but complex
• lower costs
• (Truly) Shared Database. This is the ideal scenario and the one most touted by purists. However the risk is that the different tenant data could inadvertently be mixed resulting in legal, compliance or contract issues. Also there are issues around Database sizes and multiple strategies including Partitioning and Segmentation have to be used to manage the Database. We won't go into details as there is more than adequate literature around these topics.
• Complex Upgrade process
• Impacts Multiple customers
• Data Security at Data Access Layer.
• Low Cost ( not assuming cost of design, development etc).

Which approach to choose?
Chose the Shared Database option if the number of tenants are higher to justify initial investment. However if number of users per tenant or database size per tenant or per tenant customizations are greater then choose the isolated model. 

Data-Security

Security strategies for shared database could include having views that filter the data visible to a tenant, using access control to the database itself and encryption at the data layer ( decryption at the DAC using tenant specific keys). 

Data-Extensibility

Multiple options are available including using name-value pairs to store data. Traditional data-extensibility approaches include have predefined fields and allowing extensions through metadata tables.

Data-Scalability

Data partitioning as noted in the above sections can aid in horizontal scaling of the Database.



Refer Multi-Tenant Data Architecture for further details.


Conclusion
Achieving the most optimum "degree" of multi-tenancy is something that the organization has to strive for. It could start with the Multi-Tenancy at the Infrastructure layer (IaaS), and the Platform layer (PaaS), move on to SaaS clusters that can provide some degree of Multi-Tenancy and then finally move on to the complete Multi-Tenancy at the Software layer (SaaS). 


Resources

1. Wikipedia- Multitenancy
2. Many degrees of Multi-tenancy is an excellent blog post that outlines the current debate and approaches for Multi-tenancy. 
3. Multi-Tenant Data Architecture is an excellant resource that talks about Data design patterns for Multi-Tenancy.

The opinions and statements in this communication are my own and do not necessarily reflect the opinions or policies of CA.