SW Security - 4 - Software Security section 1

ACCESS CONTROL MODELS

+ Most models contain rules with - Subject (actor)- Resource (object)- Action >> "Clark-Wilson access control triple" + Often extended with various contexts (time, location, ...) + Access Control Matrix >> Rows of roles, columns of assets (admin pages, bill pay, etc)

What is NIST SP-800-63-3 ?

Digital Identity Guidelines

Is software security a feature or a function?

Neither. Software security is about integrating security practices into the way you build software, not simply integrating security features or functions into your code.

Briefly describe DISCRETIONARY ACCESS CONTROL - DAC and its pros/cons

• Users to grant or revoke access, ownership, and delegation of rights to any of the objects under their control. • Advantage: flexible • Disadvantage: no control of information dissemination; complete trust of security policy administration given to user

List top 10 OWASP Web App vulnerabilities as of 2017

+ A1 Injection + A2 Broken Authentication and Session Management + A3 Cross-Site Scripting (XSS) + A4 Broken Access Control (As it was in 2004) + A5 Security Misconfiguration + A6 Sensitive Data Exposure + A7 Insufficient Attack Protection (NEW) + A8 Cross-Site Request Forgery (CSRF) + A9 Using Components with Known Vulnerabilities + A10 Underprotected APIs (NEW)

ROLE-BASED ACCESS CONTROL - RBAC

+ Access to an object based on the assigned role. + Roles are often defined based on job functions.• Privileges are defined based on job authority and responsibilities within a job function. ("need to know") + Operations on a resource are invocated based on the permissions associated with the privilege. • The object is concerned with the user's role and not the user. + User's change frequently, roles don't

List some categories and associated examples of personal identification info sources.

+ Authoritative source: HR System- Student Information Service + "Trust Chain": Passports and driver's licenses - SSL Certificates- Phone no, credit cards + Self + Machines: IP Address • DNS Names • SSH Host Keys • Certificates • Machine Address Code (MAC) + Services: Uniform Resource Identifier (URI) • Certificates • Images

According to IEEE, one of the top 10 design flaws is not doing authorization after an identity was authenticated. List some design principles that can help you avoid that flaw.

+ Authorization should be conducted as an explicit check, and as necessary even after an initial authentication has been completed. + Use both user's associated privilege and contextual information (i.e. time and place) in authorization scheme + Prompt authorization revocation system

Describe the main security principle regarding Attack Surface

+ Close all entry points except for the absolutely needed entry points. + Apply constraints on entry points.

Cryptography can be used to add security features to an application but that does not make an application secure. List and explain the reasons

+ Cryptography is very complex and deploying cryptography is filled with pitfalls that can easily go wrong. + Security is a system property, not a thing + Not only cryptography can't find bugs and flaws but sometimes also make it harder for debuggers and architects. + Cryptography was designed to protect data, not application that process the data. + Sometimes, cryptography even helps attackers

According to IEEE, one of the top 10 design flaws is not explicitly validate all data. List some design principles that can help you avoid that flaw.

+ Design or use centralized validation mechanism and make sure all data entering a system are validated + Transform data into a canonical form, before performing actual syntactic or semantic validation. + Use common libraries of validation primitives + Input validation requirements are often state-dependent + Explicitly re-validate assumptions "nearby" code that relies on them. Liberal use of precondition checks in the entry points of software modules and components is highly recommended. + Use implementation-language-level types to capture assumptions about data validity (i.e. use "date/time" type for date/time data)

According to IEEE, one of the top 10 design flaws is not always consider the users. List some design principles that can help you avoid that flaw.

+ Design security-related mechanisms to be easy to deploy, configure, use and update securely. + Consider how physical abilities, cultural biases, habits and idiosyncrasies of intended users and how it will impact overall security stance + Design systems that can be configured and used in a secure manner with easy-to-use, intuitive interfaces and sufficiently expressive, but not excessive, security controls + Do not assume that every intended users will be interested in security or be well-meaning

Describe the signs of Insufficient Attack protection

+ Detect and respond but lack blocking mechanism + New defenses take weeks or months to be rolled out + Not aware of all types of possible attacks

According to IEEE, one of the top 10 design flaws is Assuming Trusts. List some design principles that can help you avoid that flaw.

+ Don't assume that server APIs will always be called in the same order everytime. + Don't assume user interface is always able to restrict what the user is able to send to the server + Don't place authorization, access control, enforcement of security policy, or embedded sensitive data in client software + Assume all data sent from untrusted clients to be compromised + Take extreme measures to protect sensitive/valuable data sent to client side + Make sure all data received from clients are properly validated before processing

According to IEEE, one of the top 10 design flaws is not using Cryptography correctly. List some design principles that can help you avoid that flaw.

+ Don't use your own cryptographic algorithms or implementations (even trained mathematicians sometimes produce algorithms that have subtle problems) + Don't misuse of libraries and algorithms + Manage keys well + Implement good randomization + Centralize cryptography + Allow for algorithm adaptation and evolution

From Implementation perspective, how do we prevent Buffer Overflow?

+ Double check buffer sizes, always make sure destination buffer size is at least equal to source buffer size. + Check buffer boundaries if accessing the buffer in a loop, making sure no writing pass allocated space + Whenever possible, truncate all input strings + Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. + Assume all input in malicious. Use an "accept known good" input validation strategy (rather than blacklist) + Considers all aspects of inputs when doing input validation

DESIGN PRINCIPLES FOR ACCESS CONTROL

+ Economy of mechanism: Keep the design as simple and small as possible. +Fail safe defaults: Base access decisions on permission rather than exclusion ("no" by default) • + Complete mediation: Every access to every object must be checked for authority. + Separation of privilege: When appropriate, use two keys to unlock privileges. + Least privilege: Role contains the minimum amount of privileges; user is assigned to a role that allows him or her to perform only what's required for that role

According to IEEE, one of the top 10 design flaws is not Identify sensitive data and how they should be handled. List some design principles that can help you avoid that flaw.

+ Have policies that explicitly identify different levels of classification. Factor all relevant considerations into the design of data sensitivity (regulations, sources, contractual obligations, etc) + Not all data protection requirements are the same (each will have a different mix of C.I.A priorities) + Take care of not only data at rest but also data in transit between components, crossing multiple trust boundaries. + Regularly revisit and revise data protection policies and their design implications

Describe Session ID

+ ID of a session (session is like a phone conversation) + long, hashed, randomly generated string + Used for stateless protocols (like HTTP) + short lived with expiration time, becoming invalid when certain conditions are met + Usually represents the user (user login)

How to prevent SQL Injection from Operation and Implementation perspective?

+ If dynamically-generated queries are unavoidable, properly quote arguments and escape any special characters within the arguments. Best approach is using an extremely strict whitelist of characters. + Assume all input in malicious. Use an "accept known good" input validation strategy (rather than blacklist) + Considers all aspects of inputs when doing input validation + Use whitelist that limit character sets per expected value (for each group, each input field) + Disallow meta-characters entirely whenever possible instead of escaping them. + Ensure error messages are useful and understandable by users. Errors must be tracked to some details. Errors should not reveal the methods used to identify errors or internal state of the system. + Use an application firewall (in case codes can't be fixed)

From Implementation perspective, how do we prevent OS Injection?

+ If dynamically-generated queries are unavoidable, properly quote arguments and escape any special characters within the arguments. Best approach is using an extremely strict whitelist of characters. + If programs allow arguments to be loaded from a file or standard input, make sure only arguments are passed (instead of commands) + Assume all input in malicious. Use an "accept known good" input validation strategy (rather than blacklist) + Considers all aspects of inputs when doing input validation + Use whitelist that limit character sets per expected value (for each group, each input field) + Appropriate encoding of inputs may help + Ensure that error messages only contain minimal details that are useful to the intended audience, and nobody else. + Use logs

Describe the signs of being vulnerable to CSRF

+ Lack of CSRF token in links and forms + Lack of re-authentication/confirmation steps + Did not pay attention to state changing forms/functions + Not tested for CSRF

What is the relationship between code quality and attack surface measurement (ASM) score

+ Low ASM and Good code quality = low security risk + Good code quality and high ASM score = medium risk + Bad code quality and low ASM score = medium risk + Bad code quality and high ASM score = HIGH risk

Regarding source code security tools, we have black-box tools, static analysis tools (a.k.a source code analyzers)... While these tools are getting more powerful these days, explain why tools are not a catch all solution.

+ Most tools are still rule based and can only be as good as the collection of existing rules + Tools have limited impact and not context aware (limited by blackbox, by LOC, ...) + Bugs are only 50% of the problems (architectural flaws are the rest) + A tool is only as effective as the User of the tool + Tools can suffer from false positives and false negatives (more dangerous)

Give examples of some weak authentication management

+ Password: - Easy to guess- Written down in a non-secure location- Stealing: eavesdropping, social engineering + Physical devices: - Stolen- Copied + Biometrics: - Duplicated

Penetration testing is very important in the software development lifecycle and is the most frequently used software security practice. However, it is not a solution to the software security problem. Explain why.

+ Pen test is only as good as the pen-tester. Software owners will also not able to validate the effectiveness of a test they don't understand. + There is a risk of malicious pen-testers who keep some of identified flaws for themselves "for later". + Testing for negatives does not cover any faults. It only proves that there is no fault under certain testing conditions. + Problems should be fixed as the project develops, not at the end (in the case of pen test). Some problems can be easily found early in the lifecycle

Discuss some benefits of re-validation

+ Protect against insufficient input validation in a higher layer or from additional data-flows that were not considered during the initial security design which does not perform the same level of validation + Permit local reasoning about the correctness of a component (reduce assumptions in checks)

MANDATORY ACCESS CONTROL - MAC

+ Restrict access to objects based on the sensitivity of the objects and the formal authorization (i.e. clearance) of subjects to access information of such sensitivity. • Often used for highly sensitive government and military information • + Advantages:- Access to an object is based on the sensitivity of the object- Access based on need to know is strictly adhered to and scope creep has minimal possibility - Only an administrator can grant access + Disadvantages:- Difficult and expensive to implement- Not agile

What are the 3 pillars of software security ?

+ Risk management framework + Touchpoints + Knowledge

From Operation perspective, how do we prevent OS Injection?

+ Run code in a sandbox environment that enforces strict boundaries between the process and the OS. + Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will enforce input validation + Use runtime policy enforcement to create a whitelist of allowable commands + Use an application firewall

From Operation perspective, how do we prevent Buffer Overflow?

+ Run or compile software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows. + Use a feature like Address Space Layout Randomization (ASLR). + Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent. + Implement strategies to increase the workload of an attacker, such as leaving the attacker to guess an unknown value that changes every program execution

Perimeter security includes firewalls, SIEM products, WAFs, ... Explain why Perimeter Security can't make applications secure

+ Security has to be Built into software as it is being developed + The "perimeter" is getting blurred these days with distributed systems

We can't count on just software developers to make software secure. In fact, software security initiative (SSI) should be led by a SSG - Software Security Group. What are the possible structures for SSG ?

+ Services : Most common. SSG organized as software security services (pen test, code review, etc) + Policy : set policies but can't control the implementations/executions of policies + Business unit + Hybrid : a blend of policy and service structure + Management : managing a distributed network of others doing security work

When filtering inputs, whitelist method is prefered over blacklist method because with black list, it is so easy to miss cases. What are possible drawbacks with whitelist method?

+ Sometimes we can't block certain characters + Often requires re-compilation or patches

Briefly describe the principle "Secure by Default"

+ System default settings should be as secure as possible + All security features should be enabled by default + All features that may pose security issues should be disabled by default + All operations that reduce security should be hidden

Describe an Attack Surface.

+ The subset of system's resources potentially be used in attacks on the system It can be: + The sum of all PATHS for data to go in and out, and the codes protecting the paths (authentication, authorization, activity logging, ...) + All associated DATA (secrets, keys, business data, intellectual property, PII, ...) and the codes protecting these data

Describe OWASP - A5 Security Misconfiguration

+ Threat Agent: both anonymous and authorized users + Attack vectors: default accounts, unused pages, unpatched flaws, unprotected files and directories, etc + Security weakness: Can happen at any application stack. + Technical impact : attackers will have unauthorized access to system data or functionality, may even lead to system compromise.

Describe OWASP - A3 XSS Cross-Site Scripting

+ Threat agent: all who can send untrusted data to the system + Attack vectors: text-based attacks that exploit the interpreter. All sources of data can be attack vector + Security weakness: an application updates a webpage with attacker controlled data without properly escaping that content or using a safe JS API. XSS can be stored or reflected + Tech impact: hijack user session, deface website, insert hostile content, etc. + Business impact: consider the value of affected system, and all the data it processes.

Describe OWASP - A7 Insufficient attack protection

+ Threat agent: anyone who can send the application a request + Attack vectors (easy): applications or APIs + Security weakness (common, avg): reject attacks but don't stop them from happening again. The speed of issuing updates/patches. + Technical impact (moderate) : allowing probes will increase risks, slow release of patches will also increase risks

Describe OWASP - A1 Injection

+ Threat agent: anyone who can send untrust data to the system + Attack vectors (easy): text-based attacks that exploit the syntax of the targeted interpreter. + Security weakness (average): flaws in SQL, LDAP, Xpath, noSql queries, OS commands, XML parsers... Flaws are easy to discover during code review but hard to discover via testing. Scanners and fuzzers may help. + Technical impact (severe): data loss or corruption, denial of access, sometimes complete host take over + Business impact : important data can be stolen, modified, deleted.

Describe OWASP - A4 Broken access control

+ Threat agent: authorized users + Attack vectors: attackers who are authorized users having access to resources they're not supposed to have + Security weakness: actual name or key of an object usually used in APIs or applications. URLs and function names are frequently easy to guess. APIs don't authorize users for a target resource. + Technical impacts : data can be compromised, stolen, abused

Describe OWASP - A2 Broken Authentication and Session management

+ Threat agent: both anonymous or authorized users who may want to impersonate other users + Attack vectors: leaks or flaws in the authentication of session management functions + Security weakness: custom authentication and session management schemes were not built properly. + Technical impact: some or all accounts to be attacked + Business impacts: consider the damages when user accounts got compromised, when privilege accounts got compromised. It can lead to financial damages, leaking of important information, etc.

Describe OWASP - A9 Using components with known vulnerabilities

+ Threat agent: vulnerable components + Attack vectors (avg) : Attackers identify a weak component through scanning or manual analysis. It will be more difficult if the component is deep in the application. + Security weakness (common, avg detectability) : Most APIs have these issues. Developers don't know all components used in software especially dependencies. + Impact (moderate) : can lead to injection, broken access control, XSS, complete host take over, data compromise, etc.

Describe OWASP - A8 Cross-site Request Forgery

+ Threat agents : anyone who can load content into users' browsers, and thus force them to submit a request to website, including any website or other HTML feed that users visit + Attack vectors (avg) : attackers create forged HTTP requests and trick a victim into submitting them via image tags, iframes, XSS, or various other techniques. IF the user is authenticated, the attack succeeds + Security weakness (uncommon, easy to detect) : browser sends credentials like session cookies automatically + Impact (moderate) : victim can be tricked into performing any state changing operations that the victim was allowed

Describe OWASP - A6 Sensitive Data Exposure

+ Threat agents: Whoever can gain access to sensitive data + Attack vectors : difficult. Stolen key, man in the middle, data in transit, browser, etc + Security weakness: Not encrypting data, weak key generation and management, weak algorithm usage, weak password, browser weakness, + Technical impact : severe. Total data compromise, exposed sensitive data.

Describe OWASP - A10 Underprotected APIs

+ Threat agents: anyone with ability to send requests to APIS + Security weakness (common, difficult to detect) : Static tools don't work well on APIs and even manual analysis can be very difficult (APIs are like black boxes) + Impact (moderate) : full range attacks are possible

From implementation perspective, how do you prevent XSS ?

+ Understand the context in which your data will be used and the encoding that will be expected + Understand all the potential areas where untrusted inputs can enter your software + For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8 + set the session cookie to be HttpOnly, prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie (this however is not supported by all browsers) + assume all input is malicious, perform input validation, use whitelists, use proper encoding/decoding

List the top 3 kinds of SQL injection

+ Union query-based + Vendor specific SQL injection + Unauthorized commands SQL injection (2015 data)

What are the approaches to overcome limitations of source code security tools ?

+ Use a hybrid approach of tools (bug finding) and human evaluations (design critique) + Research and maintain best practices

How to prevent SQL Injection from Architecture and Design perspective?

+ Use a vetted library or framework or provides constructs that make this weakness easier to avoid. (use persistence layer like Hybernate or Enterprise Java Bean) + Separate data and code whenever possible. Process SQL using prepared statements, parameterized queries, or stored procedures. Do not dynamically construct and execute query strings using "exec" or similar functionality. + Run codes, create accounts using least privilege principle. Use strictest permission on all database objects (like "execute only" for stored procedures + For each security check on client side, ensure a duplicate on server side (double check) + When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

From Architecture and Design perspective, how do we prevent Buffer Overflow?

+ Use languages that are most resistant to this kind of exploit (languages with its own memory management for example) + Use vetted library or framework (Strsafe.h, etc) + For checks performed on client side, do the same checks on server side + When a set of acceptable objects are limited or known, create a mapping of fixed input to the objects and reject all other inputs. + Use least privilege principle + Run code in a sandbox environment that enforces strict boundaries between the process and the OS.

From Architecture and Design perspective, how do we prevent OS Injection?

+ Use library calls rather than external processes + Keep data relating to command generation out of external control as possible + Use vetted library or framework. Perform checks on server side + When a set of acceptable objects are limited or known, create a mapping of fixed input to the objects and reject all other inputs. + Use the least privilege principle

According to IEEE, one of the top 10 design flaws is Using an authentication mechanism that can be bypassed or tampered with. List some design principles that can help you avoid that flaw.

+ Use multi-factor authentication + Use re-authentication for important tasks in balance with usability and convenience. + Use strong authentication mechanism not just with human-computer interactions but also between softwares (APIs, etc) + Use tokens/tickets that are hard to forge + Limit the lifetime of an authentication interaction + Use a single time tested system responsible for authenticating users. + Properly store authentication information on server (use encryptions)

From architecture and design perspective, how can we prevent incorrect authorization ?

+ Use per user or session indirect object references. + Automated verification + Divide application into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. + Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries. + Perform access control checks related to your business logic (may different from generic access control) + Use vetted library or framework, checks enforced at both browser and server

According to IEEE, one of the top 10 design flaws is not strictly separate data and control instructions, and process control instructions from untrusted sources. List some design principles that can help you avoid that flaw.

+ Use strict segregation between data and control instructions + Avoid the use of injection-prone APIs + Use hardware capabilities (at lower levels) to enforce separation of code and data (i.e memory access permissions) + Avoiding exposing methods or endpoints that consume strings in languages that embed both control and data + Be very careful when using functions such as eval in programming languages + Validate and escape query languages. Use api in between application code and raw query languages. Don't use ad-hoc string concatenation + Be very careful when using reflection (i.e. serializer/deserializer)

Regarding XSS prevention, we never put untrusted data in these places. What are those places?

+ directly in a script + inside HTML comment + in an attribute name + in a tag name + directly in CSS

What is OWASP Password guideline ?

+ meet 3 out of 4 complexity rules (1 upper case, 1 lower case, 1 digit, 1 special char) + >10 char, <128 chars + Require credentials before any sensitive action (changing password, etc)

Define Confidentiality, Integrity, Availability

+Confidentiality : Degree to which the "data is disclosed only as intended" + Integrity : Degree to which a system or component guards against improper modification or destruction of computer programs or data." + Availability : Degree to which a system or component is operational and accessible when required for use."

What are the direct objects susceptible to an insecure direct object reference vulnerability?

- Files and filenames - Registry keys - Ports and network resources - Tables, columns, and rows in a database

Multi-factor authentication should be used in all authentication schemes. Describe the main factors (3)

- Something you know (account details or passwords) - Something you have (tokens or mobile phones) - Something you are (biometrics)

List software security touchpoints

1- Code review (codes) 2- Risk Analysis (tests and test results) 3- Penetration testing (test&test results, Feedback from the field) 4- Risk-based security tests (test plans) 5- Abuse cases (requirements and use cases) 6- Security requirements (requirements and use cases) 7- Security operations (feedback from the field) * External review

How to prevent security misconfiguration ?

1. A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Development, QA, and production environments should all be configured identically (with different passwords used in each environment). 2. A process for keeping abreast of and deploying all new software updates and patches in a timely manner to each deployed environment. 3. A strong application architecture that provides effective, secure separation between components. 4. An automated process to verify that configurations and settings are properly configured in all environments.

How do we prevent Data Exposure?

1. Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all sensitive data at rest and in transit in a manner that defends against these threats. 2. Don't store sensitive data unnecessarily. Discard it as soon as possible. Data you don't retain can't be stolen. 3. Ensure strong standard algorithms and strong keys are used, and proper key management is in place. Consider using FIPS 140 validated cryptographic modules. 4. Ensure passwords are stored with an algorithm specifically designed for password protection, such as bcrypt, PBKDF2, or scrypt. 5. Disable autocomplete on forms requesting sensitive data and disable caching for pages that contain sensitive data.

How to prevent the using components with known vulnerabilities issue ?

1. Continuously inventory the versions of both client-side and server-side components and their dependencies using tools like versions, DependencyCheck, retire.js, etc. 2. Continuously monitor sources like NVD for vulnerabilities in your components. Use software composition analysis tools to automate the process. 3. Analyze libraries to be sure they are actually invoked at runtime before making changes, as the majority of components are never loaded or invoked. 4. Decide whether to upgrade component (and rewrite application to match if needed) or deploy a virtual patch that analyzes HTTP traffic, data flow, or code execution and prevents vulnerabilities from being exploited.

How to protect the Underprotected APIs ?

1. Ensure that you have secured communications between the client and your APIs. 2. Ensure that you have a strong authentication scheme for your APIs, and that all credentials, keys, and tokens have been secured. 3. Ensure that whatever data format your requests use, that the parser configuration is hardened against attack. 4. Implement an access control scheme that protects APIs from being improperly invoked, including unauthorized function and data references. 5. Protect against injection of all forms, as these attacks are just as viable through APIs as they are for normal apps.

How do we check if we are vulnerable to data exposure

1. Is any of this data stored in clear text long term, including backups of this data? 2. Is any of this data transmitted in clear text, internally or externally? Internet traffic is especially dangerous. 3. Are any old / weak cryptographic algorithms used? 4. Are weak crypto keys generated, or is proper key management or rotation missing? 5. Are any browser security directives or headers missing when sensitive data is provided by / sent to the browser?

How to check if you are vulnerable to Security Misconfiguration

1. Is any of your software out of date? This software includes the OS, Web/App Server, DBMS, applications, APIs, and all components and libraries. 2. Are any unnecessary features enabled or installed (e.g., ports, services, pages, accounts, privileges)? 3. Are default accounts and their passwords still enabled and unchanged? 4. Does your error handling reveal stack traces or other overly informative error messages to users? 5. Are the security settings in your application servers, application frameworks (e.g., Struts, Spring, ASP.NET), libraries, databases, etc. not set to secure values?

List and describe 7 myths of Software security

1. Perimeter Security can secure your applications 2. A tool is all you need for software security 3. Penetration testing solves everything 4. Software security is a cryptographic problem 5. It's all about finding bugs in your code 6. Security should be solved by developers 7. Only high-risk applications need to be secured

Signs that you are vulnerable to broken authentication and session management

1. User authentication credentials aren't properly protected when stored using hashing or encryption. 2. Credentials can be guessed or overwritten through weak account management functions 3. Session IDs are exposed in the URL (e.g., URL rewriting). 4. Session IDs are vulnerable to session fixation attacks. 5. Session IDs don't timeout, or user sessions or authentication tokens (particularly SSO tokens) aren't properly invalidated during logout. 6. Session IDs aren't rotated after successful login. 7. Passwords, session IDs, and other credentials are sent over unencrypted connections.

List some ACCESS CONTROL MECHANISMs

25, PEP, XACML, ACPs PDP >> XACML: eXtensible Access Control Markup Language >> ACP = Access Control Policy <-> PDP = Policy Decision Point <-> PEP = Policy Enforcement Point <-> application codes

What is "Vulnerability" ?

A bug with security consequences A design flaw or poor coding that may lead to exploitations for malicious purposes An instance of a fault that violates security policy

Describe Security Development Lifecycle

A software development security assurance process consisting of security practices • Affects all steps in the lifecycle and the development culture • Simplified SDL has 17 practices • Uses a build-security-in/secure-by-design-philosophy

According to OWASP top 10 (2017), what are the vulnerabilities that have the most severe impact?

A1-Injection, A2- Authentication, A6-Sensitive data exposure

According to OWASP top 10 (2017), what are the vulnerabilities that are easy to exploit?

A1-Injection, A4-Access Control, A5-Misconfiguration, A7-Attack protection.

According to OWASP top 10 (2017), which vulnerability is the most wide spread?

A3 - XSS

Describe Access Reference Map

An indirect reference map is a substitution of the internal (discoverable, especially sequential) reference with an alternate ID which can be safely exposed externally. 1. Map is created on the server between the actual key and the substitution. 2. The key is translated to its substitution before being exposed to the UI. 3. After the substituted key is returned to the server, it's translated back to the original before the data is retrieved.

ATTRIBUTE BASED ACCESS CONTROL

Controls access to objects by evaluating rules against the attributes of entities (subject and object), operations, and the environment relevant to a request. Attributes are name:value pairs o possibly chained o values can be complex data structures • Associated with users, subjects, objects, contexts • Converted by policies into rights just in time

Components of the Implementation and Verification phases

Impliementation: • User approved tools • Deprecate unsafe functions • Static Analysis Verification: • Dynamic Analysis • Fuzz testing • Attack surface review

List some examples of anti XSS libraries

Microsoft's Anti-XSS library OWASO ESAPI Encoding module

SESSION MANAGEMENT

Overcoming the lack of state ....Session IDs • Random • Long (16 bytes +) • No details exposed- Name- Content • Use built-in frameworks • New sessions after any privilege change • Never cross HTTP / HTTPS • Cookies- Only sent over SSL (TLS)- HttpOnly attribute- SameSite attribute • Session Expiration- Automatic- Manual

You know an open source application was used by your target and one page has this code: $id = $_GET['id']; $getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id'"; $result = mysql_query($getid) or die('<pre>' . mysql_error() . '</pre>' ); Describe the basic steps to get admin password by attacking the page.

Page uses input without sanitization. + use sql injection to read table schema + use sql injection to get admin password + use rainbow table to decode admin password, and other crypto attack methods **of course, there will be much more challenges when it comes to real life situation

Defense in depth has 3 main components: People, Technology, Operations. List several examples for each component.

People: Policies and procedures, training and awareness, physical security... Technology: network and infrastructure, computing, environment, segmentation, encryption Operations: security management, key management, readiness assessment, recovery and reconstruction...

Components of the Release and Response phase

Release: • Incident Response Plan • Final security review • Release archive Response: • Execute incident response plan

Components of the Requirements and the design phases

Requirements : • Establish security requirements • Create quality gates / bug bars • Security and privacy risk assessment Design : • Establish Design requirements • Analyze attack surface • Threat modeling"

What is the number 1 software security touchpoint ?

Source codes --> there are numerous tools to make sure source codes are secure

Describe 7 phases of SDL

Training - Requirements - Design - Implementation - Verification - Release - Response

What is "google hacking" ?

Using google to discover (exposed) contents that can be useful in a hack like : files contain passwords, logs files with usable contents, default locations of admin consoles, human resources websites, contact lists (wml files), ....

Describe the principle "Fail securely"

When failing, applications should NOT: + Disclose any data + Provide any access + Provide too much information

Describe briefly ACCESS CONTROL POLICY

• An access control policy is composed of a sequence of rules that specify under what conditions a user/actor can access specified resources. • Describes a sequence of rules to decide whether access requests are allowed or denied - Policy .... Deals with subject, object, action

List some authentication best practices

• Emails- Correct form- Deliverable • Hash stored passwords with salts • Account lockout procedures • Externalize (e.g., Shibboleth) • Re-authenticate for sensitive operations • Effective password management- Rules (length, types of characters, ...)- No defaults- Expiration time

2017 NIST PASSWORD LIMITATIONS

• Forbid commonly used passwords • Don't use password hints or knowledge based authentication • Limit the number of password attempts

According to IEEE, one of the top 10 design flaws is not understand how integrating external components changes the attack surfaces. List some design principles that can help you avoid that flaw.

• Isolate external components as much as required functionality permits • configure external components to enable only the functionality needed • consider how included functionality (esp the unused ones) changes security posture (attack surface, inherited debt, threats, etc.), and therefore increases the security to account for the change. • If you cannot configure the security properties/objectives of the component to align with your security goals, find another library, or document that you are accepting the risk and inform relevant stakeholders of your decision. • Validate the provenance and integrity of the external component • << to be further developed >>

List some authentication protocols

• Kerberos • Transport Layer Security (TLS / SSL) • Host Identity Protocol • SAML / OAuth

BEST PRACTICES FOR ACCESS CONTROL

• Policies should be persisted and centralized • Use a policy language (XACML) • Have a centralized Access Controller • Controller manages conflicts, hierarchies, negative permissions • Keep user identity in session • Load entitlements server side from trusted source • Force authorization checks on all requests • Deny by default

Core ideas of 2017 NIST PASSWORD GUIDELINE

• Remove password complexity rules • Length matters more • No periodic password resets • Enable "Show Password" • Allow Paste in Password Fields

Describe the PRINCIPLE OF LEAST PRIVILEGE in access control

• Roles are engineered based on the principle of least privilege. • A role contains the minimum amount of permissions. • A user is assigned to a role that allows him or her to perform only what's required for that role. • No single role is given more permission than the same role for another user.

2017 NIST PASSWORD STORAGE recommendations

• Salt passwords with at least 32 bits of data • Password -based Key Derivation Function 2- At least 10,000 iterations • Stores salts separately

What could be considered "external component" to your currently developed software?

• Software procured as off-the-shelf components, platforms, and applications • Third-party open source or proprietary libraries • Widgets and gadgets added or loaded at runtime as part of a web project • Access to some functionality provided by the component that you plan to take advantage of (such as accessing a web service that provides federated authentication) • Software developed by a different team within your organization • Software that your team developed at a previous point in time (perhaps at a time when the security stance was not as mature as it is now)

SYMMETRIC ALGORITHMS

• Typical uses: secrecy and integrity of data, messages, files • Examples: - DEA (Data Encryption Algorithm) which is specified within the DES (Data Encryption Standard). (Obsolete) - Triple DES (Encrypt, Decrypt, Encrypt) 2 or 3 keys - AES (Advanced Encryption Standard) - US Standard - Skipjack, Blowfish, IDEA

What does it mean by saying "RBAC is Many-to-Many"

• Users may be assigned many roles • Roles may have many users assigned to them • Roles may be assigned to many other roles • Roles may be assigned many permissions • Permissions may be assigned to many roles • Permissions may be granted to perform many different types of operations on an object