OWASP Pro Active Controls

The OWASP Top 10 Proactive Controls 2016 is published by OWASP (Open Web Application Security Project). This is a list of security techniques should exist as a part of SDLC (Software Development Life Cycle).

1)  Verify for Security Early and Often:

This is the most important aspect of any Secure Software Development Life Cycle. Applications must be tested and verified for security in the beginning of the project and throughout the lifecycle of the project – thus any issue discovered early can be fixed early and don’t block entire project.

2)  Parameterize Queries:

SQL injection is one of the most dangerous vulnerabilities for the web applications. SQL injection allows evil attacker code to change the structure of a web application’s SQL statement in a way that can steal the data, modify the data or potentially facilitate native OS command injection. By using parameterized queries, one can prevent SQL Injection.

Here is an example of SQL Injection flaw.
This is a Unsfae JAVA code that allows an attacker to inject code into query that would be executed by the database.

 String query = "SELECT acct_balance FROM acct_data WHERE customer_name = "
   + request.getParameter("custName");
 
 try {
 	Statement statement = connection.createStatement( … );
 	ResultSet results = statement.executeQuery( query );
 }

Now, “custName” parameter is simply appended to the query allows an attacker to inject any SQL code they want.

So what can we do to avoid it? Use prepared statements with variable binding(eg. parameterized queries) should help alleviate this issue.

The following code example uses a PreparedStatement, Java’s implementation of a parameterized query, to execute the same database query.

 String custname = request.getParameter("custName"); // This should REALLY be validated too
 // perform input validation to detect attacks
 String query = "SELECT acct_balance FROM acct_data WHERE user_name = ? ";
 
 PreparedStatement pstmt = connection.prepareStatement( query );
 pstmt.setString( 1, custname); 
 ResultSet results = pstmt.executeQuery( );

3) Encode Data

Encoding help protect against many types of attacks – particularly XSS (Cross-site scripting). Encoding translates special characters into some equivalent that make safe for the target interpreter.

4) validate All Inputs

So that we can reduce or minimize the malformed data entering the system. This should not be used as a primary method to prevent XSS or SQL injection.

5) Implement Identity and Authentication Controls

Use standard methods for authentication, identity management, and session management. Ideally use appropriate guidelines for User IDs, password strength controls, securing password recovery mechanism, storing password, transmitting password etc. Additionally, it would be vital to ensure that all failures are logged and reviewed, all password failures are logged and reviews, as well as all account lockouts, are logged and reviewed.

Another option could be using authentication protocols that require no passwords – such as OAuth, OpenID, SAML, FIDO, etc.

For session management, one should consider a variety of factors such as Session ID properties – such as Name Fingerprinting, ID length, ID entropy, ID content; Use built-in language specific (though latest) session management implementation. Utilize secure cookie as much as possible. Follow best practices for Session ID lifecycle. Apply controls for Session Expiration and possible Session hijacking.

6) Implement Appropriate Access Controls

Deny access by default. Utilize Role Bases, Discretionary or Mandatory Access controls where applicable. By using access control, we are intentionally creating one more layer of security – known as authorization. Authorization is the process where requests to access a particular resource should be granted or denied. By creating access control policy we are ensuring that it meets the security requirements as described.

7) Protect Data

Encrypt your data in transit, at rest and during execution. Make sure to use strong encryption methods and libraries.

8) Implement Logging and Intrusion Detection

Log analysis and intrusion detection goes hand-in-hand. There are two ways of doing intrusion detection – Network based intrusion detection and log based intrusion detection. In this particular control, we need to design our log strategy such that we are able to detect the intrusion based on systems, networks, applications, devices,

9) Leverage Security Frameworks and Libraries

Leverage security frameworks and libraries as much as possible for your application language domain.

10) error and Exception Handling

Error messages give an attacker great insight into the inner working on your code. Thus its important to aspect of secure application development to prevent error, exceptions from leaking any information.

CIS Critical Security Controls

In the earlier post, we discussed CIS Security Benchmarks and how it can be useful to public or private organizations. In this post, we will explore some of the CIS Critical Security Controls.

The CIS Critical Security Controls, also known as CIS Controls, are a concise, prioritized set of cyber practices created to stop today’s most pervasive and dangerous cyber attacks. The CIS controls are developed, refined and validated by a community of leading experts around the world. Though it’s widely considered that by applying top 5 CIS controls, an organization should be able to reduce 85 percents of risk related to cyberattack, we will review all 20 CIS controls here for clarity sake.

  1. CSC # 1: Inventory of Authorized and Unauthorized Device
  2. CSC # 2: Inventory of Authorized and Unauthorized Software
  3. CSC # 3: Secure Configurations for Hardware and Software
  4. CSC # 4: Continuous Vulnerability Assessment and Remediation
  5. CSC # 5: Controlled Use of Administrative Privileges
  6. CSC # 6: Maintenance, Monitoring, and Analysis of Audit Logs
  7. CSC # 7: Email and Web Browser Protections
  8. CSC # 8: Malware Defenses
  9. CSC # 9: Limitation and Control of Network Ports
  10. CSC # 10: Data Recovery Capability
  11. CSC # 11: Secure Configurations for Network Devices
  12. CSC # 12: Boundary Defense
  13. CSC # 13: Data Protection
  14. CSC # 14: Controlled Access Based on the Need to Know
  15. CSC # 15: Wireless Access Control
  16. CSC # 16: Account Monitoring and Control
  17. CSC # 17: Security Skills Assessment and Appropriate Training to Fill Gaps
  18. CSC # 18: Application Software Security
  19. CSC # 19: Incident Response and Management
  20. CSC # 20: Penetration Tests and Red Team Exercises

Each of these controls has its own sub-control, which has it’s own threshold metrics (from Low Risk, Medium Risk, or High Risk). For example, our first control states that we should have an inventory of authorized and unauthorized devices. First sub-control requires us to deploy an “automated” asset inventory discovery tool and as a part of that our metric should be How many “Unauthorized” Devices present in our network at a given time. If that number is somewhere between 0-1%, that’s considered Low Risk. If that number is between 1-4%, it’s medium risk while anything above 4% is considered High Risk – and appropriate actions should be taken to mitigate such risks!

Amazon Web Services (AWS) Risk and Compliance

This is a summary of AWS’s Risk and Compliance White Paper
AWS publishes SOC1 report – formerly known as Statement on Auditing Standards (SAS) 70, Service Organization report, widely recognized auditing standard developed by AICPA (American Institute of Certified Public Accountants). 
SOC 1 audit is an in-depth audit of design and operating effectiveness of AWS’s defined control objectives and control activities. 
Type II – refers that each of the controls described in reports are not only evaluated for adequacy of design, but are also tested for operating effectiveness by the external auditor. 
With ISO 27001 certification AWS is complying with a broad, comprehensive security standard and follows best practices in maintaining a secure environment. 
With PCI Data Security Standards (PCI DSS), AWS is complying with set of controls important to companies that handle credit card information. 
With AWS’s compliance with FISMA standards, AWS complies with wide range of specific control requirements by US government agencies. 
Risk Management:
AWS management has developed a strategic business plan which includes risk identification and the implementation of controls to mitigate and manage risks. Based on my understanding, AWS management re-evaluate those plans at least twice a year. 
Also, AWS compliance team have adopted various Information Security and Compliance framework – including but not limited to COBIT, ISO 27001/27002, AICPA Trust Service Principles, NIST 800-53 and PCI DSS v3.1. 
Additionally, AWS regularly scan all their Internet facing services for possible vulnerabilities and notified parties involved in remediation. External Pen Test (VA test) are also performed by reputed independent companies and repots are shared with AWS management. 
Reports/Certifications:
FedRAMP: AWS is Federal Risk and Authorization Management Program (FedRAMPsm) compliant Cloud Service Provider. 
FIPS 140-2: The Federal Information Processing Standard (FIPS) Publication 140-2 is a US government security standard that specifies the security requirements for cryptographic modules protecting sensitive information. AWS is operating their GovCloud (US) with FIPS 140-2 validated hardware. 
FISMA and DIACAP:
To allow US government agencies to comply with FISMA (Federal Information Security Management Act), AWS infrastructure has been evaluated by independent assessors for a variety of government systems as part of their system owner’s approval process.
Many agencies have successfully achieved security authorization for systems hosted in AWS in accordance with Risk Management Framework (RMF) process defined in NIST 800-37 and DoD Information Assurance Certification and Accreditation Process (DIACAP).
HIPPA:
Leveraging secure AWS environment to process, maintain and store protected health information, AWS is enabling entities to work in AWS cloud who need to comply with US Health Insurance Portability and Accountability Act (HIPPA). 
ISO 9001:
AWS has achieved ISO 9001 certification to directly support customers who develop, migrate and operate their quality-controlled IT systems in AWS cloud. This allows customers to utilize AWS’s compliance report as evidence of their ISO 9001 programs for industry specific quality programs such as ISO/TS 16949 in auto sector, ISO 13485 in medical devices, GxP in life science, AS9100 in aerospace industry. 
ISO 27001:
AWS has achieved ISO 27001 certification of their Information Security Management Systems (ISMS) covering AWS infrastructure, data centers, and multiple cloud services. 
ITAR:
AWS GovCloud (US) supports US International Traffic in Arms Regulations (ITAR) compliance. Companies subject to ITAR export regulations must control unintended exports by restricting access to protected data to US persons and restricting physical location of that data to US. AWS GovCloud provides such facilities and comply to the required compliance requirements. 
PCI DSS Level 1:
AWS is level 1 compliant under PCI DSS (Payment Card Industry Data Security Standards). Based on February 2013 guidelines by PCI Security Standards Council, AWS incorporated those guidelines in AWS PCI Compliance Package for customers. AWS PCI Compliance package include AWS PCI Attestation of Compliance (AoC), which shows that AWS has been successfully validated against standard applicable to a Level 1 Service Provider under PCI DSS Version 3.1.
SOC1/SOC2/SOC3:
AWS publishes Service Organization Controls 1 (SOC 1), Type II report. Audit of this report is done in accordance with AICPA: AT 801 (formerly SSAE 16) and International Standards for Assurance Engagements No. 3402 (ISAE 3402). 
This dual report intended to meet a broad range of financial auditing requirement of US and international bodies. 
In addition to SOC 1, AWS also publishes SOC 2, Type II report – that expands the evaluation of controls to the criteria set forth by the AICPA Trust Service Principles. These principle defines leading practice controls relevant to security, availability, processing integrity, confidentiality, and privacy applicable to service organization such as AWS. 
SOC 3 report is publicly-available summary of AWS SOC 2 report. The report includes the external auditor’s opinion of the operation of controls based on (AICPA’s Security Trust Principle included in SOC 2 report), the assertion from AWS management regarding effectiveness of controls, and overview of AWS infrastructure and Services.