Web Application Security Policy Frameworks at TalTech IT College

1 Web Applications Security Policy Frameworks TalTech IT College, Andres K ver, 2018-2019, fall semester Web: http://enos.Itcollege.ee/~akaver/WebSec Skype: akaver Email: akaver@itcollege.ee

WebApp 2 Secure applications do no just happen they are result of an organization deciding that they will produce secure applications. Organizational management, striving towards security Security policy, derived from national standards Development methodology with security checkpoints and activities Release and configuration management Standards COBIT (US), ISO 17799 (EU), ISKE in Estonia

WebApp - organization 3 Fish starts to rot from head! Organizations, where management has security buy-in will produce/procure applications that meet basic information security principles. First step along the path of possibly secure (but probably not) to pretty secure Help them to set up correct policies/standards/rules! COBIT, ISO 17799, etc

WebApp - Development 4 Choose an development methodology and coding standards. Ad hoc development is not structured enough to produce secure apps. Choose the right methodology small teams should not consider heavy weight methodologies that identify many different roles. Large teams should choose methodologies that scale to their needs.

WebApp - Development 5 What to look for Strong acceptance of design, testing and documentation Places where security controls (threat risk analysis, peer reviews, code reviews/audits, ) can be slotted in Works for organization s size and maturity Has the potential to reduce the current error rate and improve developer productivity

WebApp - Development 6 Coding standards Architectural guidance (i.e., web tier is not to call the database directly ) Minimum levels of documentation required Mandatory testing requirements Minimum levels of in-code comments and preferred comment style Use of exception handling Use of flow of control blocks (e.g., All uses of conditional flow are to use explicit statement blocks ) Preferred variable, function, class and table method naming Prefer maintainable and readable code over clever or complex code

WebApp - development 7 Source code control git is defacto monopoly High performing software engineering requires the use of regular improvements to code, along with associated testing regimes. All code and tests must be able to be reverted and versioned.

WebApp coding principles 8 Architects and solution providers need guidance to produce secure applications by design Security principles such as confidentiality, integrity, and availability although important, broad, and vague do not change. It is a good solution when implementing data validation to include a centralized validation routine for all form input. However, it is a far better to see validation at each tier for all user input, coupled with appropriate error handling and robust access control.

WebApp coding principles 9 Asset classification Selection of controls is only possible after classifying the data to be protected. Controls applicable to low value systems such as blogs and forums are different to the level and number of controls suitable for accounting, high value banking and electronic trading systems

WebApp coding principles 10 Most likely attackers Disgruntled staff or developers Drive by attacks, such as side effects or direct consequences of a virus, worm or Trojan attack Motivated criminal attackers, such as organized crime Criminal attackers without motive against your organization, such as defacers Script kiddies

WebApp Security Architecture 11 Application architects are responsible for constructing their design to adequately cover risks from both typical usage, and from extreme attack. Application designers must cope with extreme events, such as brute force or injection attacks, and fraud.

WebApp Security Architecture 12 For each functional feature in application consider: Is the process surrounding this feature as safe as possible? In other words, is this a flawed process? If I were evil, how would I abuse this feature? Is the feature required to be on by default? If so, are there limits or options that could help reduce the risk from this feature? THINKING EVIL! - putting yourself in the shoes of the attacker. Use STRIDE/DREAD threat risk modeling (or others MS Threat Modelling, Trike, CVSS, OCTAVE, AS/NZS 4360, Mozilla SeaSponge).

WebApp Stride-Dread-OWASP 13 To perform Application Threat Risk Modeling use OWASP testing framework to identify, STRIDE methodology to Classify and DREAD methodology to rate, compare and prioritize risks, based on severity OWASP - Open Web Application Security Project, OWASP Top10 STRIDE - Spoofing Identity, Tampering with Data, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege DREAD - Damage Potential, Reproducibility, Exploitability, Affected Users, Discoverability

WebApp STRIDE threat model 14 Spoofing identity. An example of identity spoofing is illegally accessing and then using another user's authentication information, such as username and password. Tampering with data. Data tampering involves the malicious modification of data. Examples include unauthorized changes made to persistent data, such as that held in a database, and the alteration of data as it flows between two computers over an open network, such as the Internet.

WebApp STRIDE threat model 15 Repudiation. Repudiation threats are associated with users who deny performing an action without other parties having any way to prove otherwise for example, a user performs an illegal operation in a system that lacks the ability to trace the prohibited operations. Nonrepudiation refers to the ability of a system to counter repudiation threats. For example, a user who purchases an item might have to sign for the item upon receipt. The vendor can then use the signed receipt as evidence that the user did receive the package. Information disclosure. Information disclosure threats involve the exposure of information to individuals who are not supposed to have access to it for example, the ability of users to read a file that they were not granted access to, or the ability of an intruder to read data in transit between two computers.

WebApp STRIDE threat model 16 Denial of service. Denial of service (DoS) attacks deny service to valid users for example, by making a Web server temporarily unavailable or unusable. You must protect against certain types of DoS threats simply to improve system availability and reliability. Elevation of privilege. In this type of threat, an unprivileged user gains privileged access and thereby has sufficient access to compromise or destroy the entire system. Elevation of privilege threats include those situations in which an attacker has effectively penetrated all system defenses and become part of the trusted system itself, a dangerous situation indeed.

WebApp DREAD threat classification 17 DREAD is a classification scheme for quantifying, comparing and prioritizing the amount of risk presented by each evaluated threat Used to compute risk value Risk_DREAD = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) / 5

WebApp DREAD 18 Damage Potential If a threat exploit occurs, how much damage will be caused? 0 = Nothing 5 = Individual user data is compromised or affected. 10 = Complete system or data destruction Reproducibility How easy is it to reproduce the threat exploit? 0 = Very hard or impossible, even for administrators of the application. 5 = One or two steps required, may need to be an authorized user. 10 = Just a web browser and the address bar is sufficient, without authentication.

WebApp DREAD 19 Exploitability What is needed to exploit this threat? 0 = Advanced programming and networking knowledge, with custom or advanced attack tools. 5 = Malware exists on the Internet, or an exploit is easily performed, using available attack tools. 10 = Just a web browser Affected Users How many users will be affected? 0 = None 5 = Some users, but not all 10 = All users

WebApp DREAD 20 Discoverability How easy is it to discover this threat? 0 = Very hard to impossible; requires source code or administrative access. 5 = Can figure it out by guessing or by monitoring network traces. 9 = Details of faults like this are already in the public domain and can be easily discovered using a search engine. 10 = The information is visible in the web browser address bar or in a form. When performing a security review of an existing application, Discoverability will often be set to 10 by convention, as it is assumed the threat issues will be discovered.

WebApp threat modelling 21 Lets try - Microsoft Threat Modeling Tool 2016 http://aka.ms/tmt2016

WebApp security architecture 22 Security architecture starts on the day the business requirements are modeled, and never finish until the last copy of your application is decommissioned. Security is a life-long process, not a one shot accident.

WebApp Security Principles 23 Minimize Attack Surface Area Every feature that is added to an application adds a certain amount of risk to the overall application. The aim for secure development is to reduce the overall risk by reducing the attack surface area. For example, a web application implements online help with a search function. The search function may be vulnerable to SQL injection attacks. If the help feature was limited to authorized users, the attack likelihood is reduced. If the help feature s search function was gated through centralized data validation routines, the ability to perform SQL injection is dramatically reduced. However, if the help feature was re- written to eliminate the search function (through better user interface, for example), this almost eliminates the attack surface area, even if the help feature was available to the Internet at large.

WebApp Security Principles 24 Secure Defaults There are many ways to deliver an out of the box experience for users. However, by default, the experience should be secure, and it should be up to the user to reduce their security if they are allowed.

WebApp Security Principles 25 Principle of Least Privilege The principle of least privilege recommends that accounts have the least amount of privilege required to perform their business processes. This encompasses user rights, resource permissions such as CPU limits, memory, network, and file system permissions. Principle of Defense in Depth The principle of defense in depth suggests that where one control would be reasonable, more controls that approach risks in different fashions are better. Controls, when used in depth, can make severe vulnerabilities extraordinarily difficult to exploit and thus unlikely to occur.

WebApp Security Principles 26 Fail securely Applications regularly fail to process transactions for many reasons. How they fail can determine if an application is secure or not. isAdmin = true; try { codeWhichMayFail(); isAdmin = isUserInRole( Administrator ); } catch (Exception ex) { log.write(ex.toString()); }

WebApp Security Principles 27 External Systems are Insecure Many organizations utilize the processing capabilities of third party partners, who more than likely have differing security policies and posture than you. It is unlikely that you can influence or control any external third party, whether they are home users or major suppliers or partners. Therefore, implicit trust of externally run systems is not warranted. All external systems should be treated in a similar fashion.

WebApp Security Principles 28 Separation of Duties Certain roles have different levels of trust than normal users. In particular, Administrators are different to normal users. In general, administrators should not be users of the application. For example, an administrator should be able to turn the system on or off, set password policy but shouldn t be able to log on to the storefront as a super privileged user, such as being able to buy goods on behalf of other users.

WebApp Security Principles 29 Do not trust Security through Obscurity Security through obscurity is a weak security control, and nearly always fails when it is the only control. This is not to say that keeping secrets is a bad idea, it simply means that the security of key systems should not be reliant upon keeping details hidden. Simplicity Attack surface area and simplicity go hand in hand. Certain software engineering fads prefer overly complex approaches to what would otherwise be relatively straightforward and simple code.

WebApp Security Principles 30 Fix Security Issues Correctly Once a security issue has been identified, it is important to develop a test for it, and to understand the root cause of the issue. When design patterns are used, it is likely that the security issue is widespread amongst all code bases, so developing the right fix without introducing regressions is essential.

31 THE END

32

33

34

35

36