Monday, July 3, 2017

OWASP Top 10 2017



Open Web Application Security Project

An online community with a goal to raise awareness about application security. It does so by identifying some of the most critical risks facing organizations. Each year the top 10 OWASP threats are published.

Here I review the top 10 OWASP draft list for 2017.  Formal publication is not expected till July/August.

Injection
Vulnerability
All involve allowing untrusted or manipulated requests, command or queries to be executed by a web application. These requests bypass the applications intended logic
e.g.
SQL Injection
Code Injection
OS Commanding
XML Injection
Buffer Overflow

Preventions
Use a vetted library/framework
Use an api, avoiding the use of an interpreter
Run the app with minimum privileges
Input sanitization i.e. whitelist only allowed characters

Broken Authentication and Session Management
Vulnerability
Capture or Bypass the authentication methods used by a web app. A session id is created following login and these needs to be secured.

Preventions
Avoid unencrypted conections
Avoid predictable login credentials. web ap needs to enforce strong passwords
Ensure session id timeouts and when a user logs out
credentials need to be hashed or encrypted
Do not use session ids in the url

Cross Site Scripting
Vulnerability
Injected of untrusted snippets of Javascript are placed into web application. The script is executed by the victim who is visiting the target site. 3 primary types
Reflected XSS. An attacker sends the victim a link that has an embedded script
Stored XSS. An attacker is able to plant a persistent script on the web site
DOM based XSS.

Preventions
Use a vetted library/framework
input validation
output encoding

Broken Access Control
Vulnerability
Access control, sometimes called authorization, is how a web application grants access to content and functions to some users and not others. These checks are performed after authentication, and govern what ‘authorized’ users are allowed to do. Access control are insidiously difficult to implement correctly.

Preventions
Insecure Id’s: Web applications should not rely on the secrecy of any id’s for protection.
Forced Browsing Past Access Control Checks:  Many sites require users to pass certain checks before being granted access to certain URLs that are typically ‘deeper’ down in the site. These checks must not be bypassable
Path Traversal: Such attacks try to access files that are normally not directly accessible by anyone, or would otherwise be denied if requested directly.
File Permissions  Only: Files that are specifically intended to be presented to web users should be marked as readable using the OS’s permissions mechanism, most directories should not be readable, and very few files, if any, should be marked executable.
Client Side Caching: Developers should use multiple mechanisms, including HTTP headers and meta tags, to be sure that pages containing sensitive information are not cached by user’s browsers


Security Misconfiguration
Vulnerability
Incorrectly assembling the safeguards for a web application.  These misconfigurations typically occur when holes are left in the security framework of an application by systems administrators, DBAs or developers.  They can occur at any level of the application stack including the platform, web server, application server, database, framework and custom code. These security misconfigurations can lead an attacker right into the system and result in a partially or even totally compromised system.

Preventions
Develop a repeatable process to reduce the surface of vulnerability
Disable default accounts and change passwords
Keep software up-to-date
Develop a strong application architecture that effectively isolates components and encrypts data which is especially important with sensitive data.
Disable any unnecessary files or features
Don’t present stack tracers to users
Ensure security settings in development frameworks and libraries are set to secure values
Run tools (i.e. automated scanners) and perform regular audits to identify holes in the security configuration


Sensitive Data Exposure
Vulnerability
Sensitive data exposure vulnerabilities can occur when an application does not adequately protect sensitive information from being disclosed to attackers. For many applications this may be limited to information such as passwords, but it can also include information such as credit card data, session tokens, or other authentication credentials.
Preventions
Don’t store sensitive data if you don’t need it. Be sure to encrypt the necessary sensitive data during storage, transit, and display.
Salting and encrypting sensitive data in storage, using TLS/SSL on pages displaying sensitive data, disabling caching of these pages

Insufficient Attack Protection
Vulnerability
Applications need to detect, prevent, and respond to both manual and automated attacks
Preventions
Defense in Depth: Implemented more than one security control supporting each other. E.g. deploy secure code, but also use technologies like Web Application Firewalls (WAFs) to prevent some kinds of attacks.
A strong application architecture that provides effective, secure separation between components and tenants.
Detect Attacks: Detect unexpected conditions early in the code and generate appropriate logging messages and security alerts. Correlate the logging of all involved components.
Respond to Attacks: Attacks may be critical to timely reaction. Decide by kind and severity whether to respond automatically (e.g. through OWASP AppSensor) or manually, e.g. develop temporary virtual patches using a WAF.

Cross-Site Request Forgery
Vulnerability
A malicious website will send a request to a web application that a user is already authenticated against from a different website. This way an attacker can access functionality in a target web application via the victim's already authenticated browser.
Preventions
The most common method to prevent Cross-Site Request Forgery (CSRF) attacks is to append unpredictable challenge tokens to each request and associate them with the user’s session. Such tokens should at a minimum be unique per user session, but can also be unique per request. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from a source other than the user

Using Components With Known Vulnerabilities
Vulnerability
Vulnerabilities in third-party libraries and software are extremely common and could be used to compromise the security of systems using the software.

Preventions
Keep frameworks, modules and components up to date. Ensure that the latest patches are installed. Maintain a non-production system to test the patches. Have a split between Dev, Test and Live environments with easy ways to move new code from Dev to Test to Live during your testing process.
Another important tactic in guarding against vulnerabilities in third party frameworks, modules and components is to only use the parts that you need to deliver the application or service. Disable those parts you are not using.
Stay up to date with supplier security bulletins, project blogs, release notes, and with the information published on trusted security sites.



Underprotected APIS
Vulnerability
All the different types of injection, authentication, access control, encryption, configuration, and other issues can exist in APIs just as in a traditional application.
Preventions
Ensure client server API communications are secured
Use strong authentication, and access control scheme
Parser configuration is hardened



Footnote

Security needs to be incorporated throughout the lifecycle
  • Threat Modeling/ Security Assess Application
  • Secure Design and Review
  • Secure Coding and Code Review
  • Penetration Testing
  • Remediation

Other publications include the 
           OWASP wiki
https://www.owasp.org/index.php/Main_Page

           OWASP Developer’s Guide
https://www.owasp.org/index.php/OWASP_Guide_Project

           OWASP Testing Guide
https://www.owasp.org/index.php/OWASP_Testing_Project

           OWASP Code Review Guide
https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

           OWASP Prevention Cheat Sheets
https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series

           OWASP ASVS – Application Security Verification Standard
https://www.owasp.org/images/3/33/OWASP_Application_Security_Verification_Standard_3.0.1.pdf

Sunday, June 25, 2017

CCSK Certificate of Cloud Security Knowledge



The Cloud Security Alliance (CSA) promote the use of best practices for providing security assurance within Cloud Computing. 

The CCSK qualification is developed by the CSA. The aim is to bring a common understanding of cloud security concepts and help increase the quality of risk decisions when moving IT to the cloud. The qualification is generic and vendor neutral.

The body of knowledge covers 14 domains, and also the European Network & Information Security Agency Cloud Computing publication: Benefits, Risks and Recommendations for Information Security

CCSK domains
Domain 1 Architecture
Domain 2 Governance and Enterprise Risk Management
Domain 3 Legal Issues: Contracts and Electronic Discovery
Domain 4 Compliance and Audit Management
Domain 5 Information Management and Data Security
Domain 6 Interoperability and Portability
Domain 7 Traditional Security, BCP and DR
Domain 8 Data Center Operations
Domain 9 Incident Response
Domain 10 Application Security
Domain 11 Encryption and Key Management
Domain 12 Identity, Entitlement and Access Management
Domain 13 Virtualisation
Domain 14 Security As A Service



ENISA Risks
Policy and organizational risks
R.1 Lock-in
R.2 Loss of governance
R.3 Compliance challenges
R.4 Loss of business reputation due to co-tenant activities
R.5 Cloud service termination or failure
R.6 Cloud provider acquisition
R.7 Supply chain failure
Technical risks
R.8 Resource exhaustion (under or over provisioning)
R.9 Isolation failure
R.10 Cloud provider malicious insider - abuse of high privilege roles
R.11 Management interface compromise (manipulation, availability of infrastructure)
R.12 Intercepting data in transit
R.13 Data leakage on up/download, intra-cloud
R.14 Insecure or ineffective deletion of data
R.15 Distributed denial of service (DDoS)
R.16 Economic denial of service (EDOS)
R.17 Loss of encryption keys
R.18 Undertaking malicious probes or scans
R.19 Compromise service engine
R.20 Conflicts between customer hardening procedures and cloud environment
Legal risks
R.21 Subpoena and e-discovery
R.22 Risk from changes of jurisdiction
R.23 Data protection risks
R.24 Licensing risks
Risks not specific to the cloud
R.25 Network breaks
R.26 Network management (ie, network congestion / mis-connection / non-optimal use)
R.27 Modifying network traffic
R.28 Privilege escalation
R.29 Social engineering attacks (ie, impersonation)
R.30 Loss or compromise of operational logs
R.31 Loss or compromise of security logs (manipulation of forensic investigation)
R.32 Backups lost, stolen
R.33 Unauthorized access to premises (including physical access to machines and other facilities)
R.34 Theft of computer equipment
R.35 Natural disasters
 

Full documentation on V3 of CCSK knowledge available here

The CSA have also created the template Cloud Controls Matrix as a baseline standard of security controls to consider when selecting a Cloud Service Provider

The European Network and Information Security Agency (ENISA) whitepaper

Further info on the exam here