Comptia Security+ 601 Chapter 6 Summary

March 3, 2023, 5:52 a.m.

CompTIA Security+ Study Guide: Exam SY0-601 8th Edition, by Mike Chapple & David Seidl

Chapter 6 summary of my notes.

Software development life cycle(SDLC) = steps in a model for software development throughout its life.

The phase of SDLC:

Feasibility phase = initial investigations into whether the effort should occur are conducted. Also looks at alternative solutions and high-level costs for each solution proposed. It results in a recommendation with a plan to move forward.

Analysis and Requirements Definition phase = customer input is sought to determine what the desired functionality is, what the current system or application currently does and what it doesn’t do, and what improvements are desired. Requirements may be ranked to determine which are most critical to the success of the project. Security requirements definition is an important part of the analysis and requirements definition phase. It ensures that the application is designed to be secure and that secure coding practices are used.

Design phase = design for functionality, architecture, integration points and techniques, dataflows, business processes, and any other elements that require design consideration.

Development phase = testing of parts of the software, including unit testing, the testing of small components individually to ensure they function properly.

Testing and Integration phase = formal testing with customers or others outside of the development team. Individual units or software components are integrated and then tested to ensure proper functionality. In addition, connections to outside services, data sources, and other integration may occur during this phase. During this phase user acceptance testing (UAT) occurs to ensure that the users of the software are satisfied with its functionality.

Training and Transition phase/ Acceptance, Installation, and Deployment phase = ensuring that end users are trained on the software and that the software has entered general use.

Ongoing Operations and Maintenance phase = once a project reaches completion and then patching, updating, minor modifications, and other work becomes daily support.

Disposition phase = once a product or system reaches the end of its life, it’s important to shut down old products to produce cost savings, replace existing tools that may require specific knowledge or additional effort, and data and systems may need to be preserved or properly disposed of.

Development environment = where developers do their work.

Test environment = testing code without impacting production. Quality assurance (QA) activities take place in the test environment.

Staging environment = transition environment for code that has successfully cleared testing and is waiting to be deployed into production.

Production environment = live system. Software, patches, and other changes that have been tested and approved move to production.

Three developmental models:

Waterfall = sequential in which each phase is followed by the next, non-overlapping phase.

Spiral = linear development like waterfall + iterative process that revisits four phases multiple times during the development life cycle:

Identification, or requirements gathering, which initially gathers business requirements, system requirements, and more detailed requirements for subsystems or modules as the process continues.

Design, conceptual, architectural, logical, and sometimes physical or final design. Build, which produces an initial proof of concept and then further development releases until the final production build is produced.

Build, which produces an initial proof of concept and then further development releases until the final production build is produced.

Evaluation, which involves risk analysis for the development project intended to monitor the feasibility of delivering the software from a technical and managerial viewpoint. As the development cycle continues, this phase also involves customer testing and feedback to ensure customer acceptance.

Agile = iterative and incremental. Four basic premises:

Individuals and interactions are more important than processes and tools.

Working software is preferable to comprehensive documentation.

Customer collaboration replaces contract negotiation.

Responding to change is key, rather than following a plan.

With Agile, work is broken up into short working sessions, sprints, that can last days to a few weeks.

The Agile methodology is based on 12 principles:

Ensure customer satisfaction via early and continuous delivery of the software.

Welcome changing requirements, even late in the development process.

Deliver working software frequently (in weeks rather than months).

Ensure daily cooperation between developers and businesspeople.

Projects should be built around motivated individuals who get the support, trust, and environment they need to succeed.

Face-to-face conversations are the most efficient way to convey information inside the development team.

Progress is measured by having working software.

Development should be done at a sustainable pace that can be maintained on an ongoing basis.

Pay continuous attention to technical excellence and good design.

Simplicity—the art of maximizing the amount of work not done—is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

Teams should reflect on how to become more effective and then implement that behavior at regular intervals.

DevOps combines software development and IT operations to optimize the SDLC. This is done by using toolchains to improve the coding, building and test, packaging, release, configuration and configuration management, and monitoring elements of a software development life cycle.

DevSecOps = security is a shared responsibility that is part of the entire development and operations cycle.

Logging, reporting, and continuous monitoring must all be designed to fit the CI/CD process.

Continuous integration (CI) = development practice that checks code into a shared repository on a consistent ongoing basis.

Continuous deployment (CD) = rolls out tested changes into production automatically as soon as they have been tested.

Open Web Application Security Project (OWASP)

Top OWASP proactive controls for 2018:

Define Security Requirements

Implement security throughout the development process.

Leverage Security Frameworks and Libraries

Preexisting security capabilities can make securing applications easier.

Secure Database Access

Prebuild SQL queries to prevent injection and configure databases for secure access.

Encode and Escape Data

Remove special characters.

Validate All Inputs

Treat user input as untrusted and filter appropriately.

Implement Digital Identity

Use multifactor authentication, secure password storage and recovery, and session handling. 13. Enforce Access Controls

Require all requests to go through access control checks, deny by default, and apply the principle of least privilege.

Protect Data Everywhere

Use encryption in transit and at rest.

Implement Security Logging and Monitoring

Handle all Errors and Exceptions

Errors should not provide sensitive data, and applications should be tested to ensure that they handle problems gracefully.

Application programming interfaces, APIs, = interfaces between clients and servers or applications and operating systems that define how the client should ask for information from the server and how the server will respond.

Code review processes:

Pair programming = two developers at one workstation. One writes code, the other reviews the code as it’s written.

Over-the-shoulder = the developer who wrote the code to explain the code to the other developer.

Pass-around code review = manual peer review done by sending completed code to reviewers who check the code for issues.

Tool-assisted code reviews = formal or informal software-based tools to conduct code reviews.

Manual code review.

Fagan inspection = structured, formal code review intended to find a variety of problems during the development process.

Static code analysis = reviewing the code for an application.

Dynamic code analysis = execution of the code while providing it with input to test the software.

2. Attack methodology

Fuzzing = sending invalid or random data to an application to test its ability to handle unexpected data.

Injection vulnerabilities are a primary method to break web applications.

Blind SQL injection is an attack when results are not able to be reviewed.

XML injection attack = embedding code in Extensible Markup Language, XML, documents.

DLL injection attack = loading dynamically linked libraries, DLLs, with malicious code

Session hijacking attack = stealing an existing authenticated session.

Session Replay attack = using a stolen cookie to perform cookie manipulation to alter the details sent back to the website or simply use the cookie as the badge required to gain access to the site.

The NTLM pass-the-hash attack = a form of replay attack that takes place against the operating system rather than a web application. Gain access to a Windows system and then harvest stored NTLM password hashes.

Directory traversal only works if files stored elsewhere on the server are unrestricted.

For Linux operating systems, the “..” operator in a file path refers to the directory one level higher than the current directory. “/var/www/html/../” is one level higher than the html directory, or “/var/www/”.

File inclusion attacks = executing code contained within a file, allowing an attacker to fool the web server into executing arbitrary code.

Local file inclusion attacks seek to execute code stored in a file located elsewhere on the web server.

Remote file inclusion attacks allow the attacker to go a step further and execute code that is stored on a remote server.

Cross-site scripting (XSS) = Potential whenever a website allows for user input. Malicious actor can place malicious javascript into an input field and submit it. If there is no validation client-side or server-side then the javascript is executed.

Input validation is important.

Refelected XSS and DOM XSS.

Stored XSS(cross-site scripting) = submitting a link to be stored on a server that communicated with a remote server that has code on it. They are persistent, because they remain on the server.

Example = You visit a blog with a comment section. A malicious user included javascript in a comment that takes data from a user and sends it out. Upon loading the comment section, that javascript command triggers for you and you unknowingly send some data to the malicious user. Your browser automatically executes the javascript by simply loading the page. And it all happens in the background.

Cross-site request forgery attacks, XSRF or CSRF, are similar to cross-site scripting attacks but exploit a different trust relationship.

CSRF = attackers embed code in one website that sends a command to a second website.

Example = a user goes to a malicious website and clicks a “about me” link. This link loads the about me page, but in the background your request is also sent off to bank X. Since you happen to be logged in and authenticated to bank X in another browser, your request also contains your authentication cookies, the bank looks at the cookies and accepts the request, and it successfully triggers a transfer of $1000 dollars to the malicious user’s account. The way browsers are designed allows for this all to happen in the background without you knowing. Cookies are automatically sent to websites when you visit(request) them. The malicious actor is guessing that you are authenticated with bank X, and makes you submit the request and therefore send the cookies. Because of Same Origin Policy, the malicious webpage is automatically blocked by the browser from receiving any responses.

Server-side request forgery (SSRF) = getting a server to visit an internal URL based on user-supplied input. If the server has access to nonpublic URLs, an SSRF attack can

unintentionally disclose that information to an attacker.

Validate input server-side.

Client-side validation is for providing users with feedback on their input.

Parameter pollution circumvents client-side validation by sending a web application more than one value for the same input variable.

3. Defenses

Web application firewalls. WAFs, work at the Application layer and sit in front of a web server.

Database normalization = set of database design principles. Databases that follow these principles are in normal forms. The simplest normal form = (1NF). Advanced normal forms follow sequentially = (2NF, 3NF, etc.). Principles:

Prevent data inconsistency.

Prevent update anomalies.

Reduce the need for restructuring existing databases.

Make the database schema more informative.

Data minimization is the best defense. Ways to minimize:

Tokenization replaces personal identifiers with a unique identifier using a lookup table.

Hashing uses a cryptographic hash function to replace sensitive identifiers with an irreversible identifier. Salting these values with a random number prior to hashing them makes the hashed values resistant to a rainbow table attack.

<b>4. Code Methodology</b>

Code signing = a way to confirm the authenticity of code for end users.

Code repositories = central place to store/manage code. Allows for version control. Useful for avoiding the buildup of dead code.

Scalability = ability for computing resources to be incrementally added to support increasing demand.

Elasticity = ability to automatically provision resources to scale when necessary and then automatically deprovision those resources when no longer needed.

Overly verbose error handling may allow an attacker to find a way to exploit the code.

<b>5. More Vulnerabilities</b>

Resource Exhaustion = (memory,storage,cpu) consumed and system is crippled or disabled.

Memory leak = application fails to return some memory it no longer needs

Memory Pointers = an area of memory that stores an address of another location in memory.

Buffer overflow = manipulating a program into placing more data into an area of memory than is allocated for that program’s use, overwriting other information in memory with instructions that may be executed by a different process running on the system.

CVE 2003-0818: Multiple integer overflows in Microsoft ASN.1 library:

One listed vulnerability = integer overflow which is a variant of a buffer overflow where the result of an arithmetic operation attempts to store an integer that is too large to fit in the specified buffer.

The four-digit number following the letters CVE in each vulnerability title indicates the year that the vulnerability was discovered.

Race conditions occur when the security of certain code depends upon the sequence of events occurring within the system.

Time-of-check-to-time-of-use (TOCTTOU or TOC/TOU) = race condition that occurs when a program checks access permissions too far in advance of a resource request.

Unprotected APIs may lead to the unauthorized use of functions if an attacker can fuzz out the api urls.

Device drivers require low-level access to the operating system and run with administrative privileges so malicious drivers can take complete control of a system.

Refactoring = modifying driver source code to also include malware elements.

Shimming = wrapping a legit driver with a malicious driver and simply sending any requests to legit drive to process.