Security in SDLC

Introduction

• The number-one reason for data breaches is insecure software, causing between 26% and 40% of leaked and stolen records in 2019.
• Universities teach students how to code, but don't teach them how to ensure code security, and most programs barely touch on application security. Training is expensive and there's no clear career path to become an application security engineer.
• Application security is difficult because each piece of custom software is unique and assumptions must never be made; verification is key.

Pushing Left

• Requirements come before design, which comes before coding, so security should be addressed from the beginning, or flaws and bugs will occur.
• It costs more to fix a flaw or bug the later in the project it is found. Shifting left means you start doing security activities earlier in the software development project, for better results.

About the Book

• The book teaches foundations of application security designed for software developers or information security professionals wanting to know more about the security of software and application.
• Alice and Bob may be recalled from other security examples; they have been used to simplify complex topics since advent of cryptography and encryption.

Out-of-Scope Topics

• Topics excluded from the book are incident response, network monitoring and alerting, cloud security, infrastructure security, network security, security operations, Identity and Access Management (IAM), enterprise security, support, and anti-phishing

The Answer Key

• Exercises at the end of each chapter help readers learn and test their knowledge and the answer keys are available at the end of each chapter, however they may be incomplete due to the nature of the questions.

Security Fundamentals: CIA

• Every IT security team aims to protect the confidentiality, integrity, and availability of systems and data for their organization. Alice uses implanted device to check insulin several times daily, while Bob has a "smart" pacemaker regulated via a mobile app.
• Confidentiality means keeping things private which is of high importance to Alice as Alice does not want to have anyone know that she has Type 1 diabetes.
• Integrity means keeping data correct and unaltered which is the most crucial in order to avoid incorrect treatments. A loss of Integrity in the devices could result in death for both Alice and Bob.
• Availability means ensuring systems are always working. Bob's pacemaker needs to be available and working correctly at all times as a life-or-death situation, while Alice is still able to manually check her insuline should the system fail.

Resilience Improves Availability

• Resilience improves availability, in public clouds for example. For Bob and Alice, they both require resilient systems
• Many well-known concepts within the information security industry should be well understood.

Assume Breach

• Assume breach means preparing with design considerations to make unauthorized access to your network, difficult, expensive, or risky.
• It requires logging of your systems to be able to detect breaches and monitoring systems for changes or anomalies to detect potential breaches. Coordinated disclosure is when disclosure of a vulnerability or issue is revealed after a period of time of discovering.
• For Alice, this would mean that when opening an online account, she wouldn't upload anything sensitive there, then for Bob at work, every aspect of the secrets would be controlled and protected.

Insider Threats

• Employees using software improperly is an accidental threat, whereas an employee downloading sensitive files for blackmail breaks confidentiality

Defense in Depth

• Layers of security can include certain processes, physical, or hardware systems, and built-in design choices. It's important to convince someone that one defense is not enough.

Least Privilege

• Granting users exactly how much access they require means an intruder can't get very far. Creating a service account for accessing a database reduces the risk greatly.

Supply Chain Security

• Everything used to create a product is considered part of your "supply chain". Modern applications are typically made up of 20 to 40 percent original code. It's a good idea to have fewer dependencies and to vet what's in your software.
• An open source Node.js called event-stream was passed on to a new maintainer in 2018 who added malicious code and downloaded via NPM then used the vulnerabilited to steal bitcoins from Copay wallets.

Security by Obscurity

• Something hidden will be more secure, which mean that the source code is hidden for security measure but this is often not enough.

Attack Surface Reduction

• Everything in your software that can be attacked is the attack surface which can be reduced by removing code before publishing. Alice could disable her insulin measuring device's Bluetooth “discoverable” setting and Bob could hide the SSID of his pacemaker

Hard Coding

• Programming values into the code leads to a situation where you cannot trust the output, values are often of a sensitive nature, and anyone with access to the source code would therefore have access to those hard-coded values

Never Trust, Always Verify

• Never trust anything outside of the application; verify that an API has the authority to do whatever it's trying to do. XSS happens when a program does not perform proper input validation.
• Stored XSS happens when a program does not perform proper input validation, and it saves an XSS attack into database or is a security questions as of this writing because it easy to cricumvent.

Usable Security

• Security features can have a way of making your application hard to use. One such type of example would be Allowing a fingerprint, facial recognition, or pattern to unlock your personal device instead of a long and complicated password.

Factors of Authentication

• Authentication is verifying that your are whom you say that you are. Authentication includes something you have, something you are and something you know. Security questions are passe, and are too easily circumvented by attackers.

Security Requirements

• When embarking on any project, there must be requirements for what is going to be built.
• The security team should take part in the project meeting from its very inception and work towards the matrix model to ensure security is well implemented. Software project should also include include security questions surrounding if the personal information being handled is sensitive or confidential

Encryption

• Cryptography is a type of math that can be applied to information in order to make its value no longer understandable
• When working within a system, we want to ensure that the CIA triad will continue such if a system were to call for changes, we must be certain to include bounding as well.

Never Trust System Input

• Never trust System Input as the inputs could cause your application to malfunction, and it makes is go into an undesirable state
• One of the main risks to computer software is when code and data are are being applied which commonly is known as an Injection vulnerability. With the # 1 threat to secure software since the start of industry.
• Following are examples of input to your application : user input on the screen, Information from a database ( the database you designed for your app) or from an API , information from another application, Values in the URL parameters, cookie values, configuration files, hidden fields
• It is essential that your application validates the Input first, then uses It.

Encoding/Escaping

• The most commonly known security vulnerability in web applications is cross-site scripting (XSS); which in its own way means removing the special powers.
• Encoding is a changing value from whatever format it is in into whatever format you are encoding for for what every you are using It as.. It is likely obvious, encode escape and all output as it is the commander here!
• It is worth the effort to add all three of these defenses to all of your applications such as Applying the “defense in depth" principle.
• With XSS being the code that is executed on the client side in the browser. That all other injection vulnerabilities are executed on the server side at the interpreter level ,and or the operating System.

Third-Party Components

• If it is insecure, your application now is also insecure if it accesses /uses/ calls that part of component.
• A Quicky, easy, and cheap win in regard to understanding how secure your application is by Verifying that all third party components are not known to be at fault..

Known Vulnerable

• Known Vulnerable; is not custom. Is often just called “customizable ( COTS Commercial / Customizable Configurable OFF The Shelf

Security Headers: Seatbelts for Web Apps

• security headers are a lot like seatbelts; they aren't sexy or exciting, they aren't difficult to use or time consuming, and if you create a habit of using them, they can save you in an emergency (such as a car accident or an attack against your web application, respectively)
• The absolute easiest setting is to just block everything, which is a good choice if your site is static and / or boring (doesn't call any content from anywhere). the settings for this is Content-Security-Policy: default-src; block-all-mixed-content; A Nonce is a string of characters created to be used one single time to prove that a specific script Is the one you mean to call

Securing Your Cookies

• Secure flags/ Cookies that the browser has the only sent only over encrypted (HTTPS) channels If an attacker asks attempt to downgrade your Session to HTP, your web application will refuse to send the cookies. You can do so using Setting Cookie Secure for all your other settings!

Never Trust System Input

• A lot of items within your application can be manipulated out side your plan. For example a user can change a URL parameter. Code must be validated at all times before input is considered trustworthy.

Chapter 3 Notes:

Design Flaw vs. Security Bug

• A design flaw is an error in design of the application where malicious or damaging action could occur, whereas a security bug is an implementation issue, a problem with the code which results in said action.

Protecting Sensitive Data

• When coding, you must ensure that no data should be used or be open to Public. When private or unclassified you must ensure it is well protected along proper lines.

Security/ Function Isolation:

• In order to do this: we separate the code so that if a given function is broken then other area are restricted. We would also force the user to properly authenticate at all times. We will also ensure that the data or code must be safely secured during runtime.