In this section of the course,
we are going to discuss Security in Systems.
The Security in Systems section of the course
focuses on Domain 2: Security Architecture,
specifically objective 2.2,
which states that given a scenario,
you must be able to implement security
in the early and subsequent states of a system's life cycle.
Securing complex systems requires a proactive strategy
that begins with including security concepts
into every component of the hardware and software life cycle
right from the outset.
Security and systems further requires thorough validation
at each stage of deployment and development
to ensure that vulnerabilities are minimized
and addressed promptly.
Finally, maintaining a strong security posture
also involves continuous evaluation and adaptation
as the secure system evolves.
This secures it against emerging and evolving threats.
As we go through this section, we will cover many topics
related to Security in Systems,
including Hardware Assurance, Security Requirements,
Software Assurance, Supply Chain Assurance,
Pre and Post-deployment Testing,
Continuous Integration/Continuous Deployment
Management and Testing, and End-of-life Considerations.
First, we will look at Hardware Assurance.
Hardware assurance ensures
that physical components are secure, reliable,
and free from malicious alterations or defects.
Hardware assurance concepts
include the certification and validation process.
The certification process is a formal evaluation
that verifies hardware components
meets specific security standards and operate as expected.
Validation is the ongoing process of testing and verifying
that hardware meets its design standards,
especially when updates or changes are made.
For example, a government agency may require hardware
used in critical systems
to undergo a rigorous certification process,
followed by a regular validation check
to ensure the hardware remains secure.
Next, we will explore Security Requirements.
Security requirements are the specific criteria
a system must meet to ensure protection
against security threats and vulnerabilities.
Security requirements can be categorized
as functional or non-functional.
Functional security requirements
define specific security-related behaviors
and features that a system must have,
such as authentication mechanisms,
access controls, and encryption protocols.
Non-functional security requirements
focus on the qualities of the system,
including its performance, reliability, and usability.
A common challenge in security requirement implementations
is security versus usability.
This can require a trade-off,
such as increasing security measures
like multi-factor authentication,
which may reduce user convenience and accessibility.
After that, we will look at Software Assurance.
Software assurance is the process of ensuring
software is developed and maintained
in a way that consistently meets
security and reliability standards.
This protects the software from vulnerabilities
and malicious threats.
Software assurance concepts
include a Software Bill of Materials,
Software Composition Analysis,
and Formal methods of validating software correctness,
safety, and security.
First, a Software Bill of Materials
is a comprehensive list of all components,
libraries, and dependencies used in a software application
to provide transparency in the software's construction.
Next, Software Composition Analysis
involves scanning and analyzing the components
and dependencies of software applications
to identify known vulnerabilities or licensing issues.
Finally, Formal Methods of Validation
are mathematically based techniques
used to verify the correctness and security
of software algorithms and systems.
Next, we will explore Supply Chain Assurance.
Supply Chain Assurance ensures that all components
and processes within the supply chain,
from vendors to delivery,
meet security and quality standards.
This prevents the introduction of vulnerabilities
into the final system.
Supply Chain Assurance concepts
include managing both hardware and software risk.
Supply Chain Risk Management for hardware
focuses on evaluating and securing physical components
from potential threats such as tampering, counterfeit parts,
or vulnerabilities introduced
during manufacturing and distribution.
For software, Supply Chain Risk Management
involves assessing and managing risks
related to third-party software components,
such as vulnerabilities or compliance issues
that could affect the overall security of the system.
For example, a financial institution
ensuring the security of its trading platform
will vet hardware components for integrity and authenticity,
which prevents tampering or the use of counterfeit parts.
Simultaneously, the financial institution
will assess third-party software libraries
for vulnerabilities and compliance issues.
This will ensure that both hardware and software components
meet security standards
to protect the overall financial trading platform.
Following that, we will look at Pre-Deployment Testing.
Pre-Deployment Testing is used to evaluate software
for security vulnerabilities, functional issues,
and performance concerns
before the software is released into a live environment.
Pre-Deployment Testing concepts
include Static Application Security Testing or SAST,
Dynamic Application Security Testing or DAST,
and Interactive Application Security Testing or IAST.
Static Application Security Testing
analyzes source code or binaries
for vulnerabilities without executing the software.
It identifies issues such as coding flaws
and security weaknesses early in the development process.
Dynamic Application Security Testing
examines the running application for vulnerabilities
by simulating attacks to uncover issues
that occurred during runtime, such as injection flaws
or authentication weaknesses.
Interactive Application Security Testing combines elements
of both Static Application Security Testing
and Dynamic Application Security Testing,
by integrating testing with a running application
to provide real-time feedback on vulnerabilities.
As compared to pure static
or Dynamic Application Security Testing,
Interactive Application Security Testing
offers a more comprehensive analysis.
For example, during the development
of a new e-commerce application,
as developers are running functional tests,
an interactive application security testing tool
can dynamically analyze the application in real-time.
This can detect issues such as improper input validation
and insecure data storage.
The Interactive Application Security Testing tool
could then provide immediate feedback
on those vulnerabilities,
allowing developers to address them promptly
before the application is deployed.
Then we will explore Post-Deployment Testing.
Post-Deployment Testing is used to evaluate software
after it has been released into a live environment,
to identify and address any security vulnerabilities
and performance issues.
Post-Deployment Testing concepts
include Vulnerability Analysis
and Runtime Application Self-Protection or RASP.
Vulnerability Analysis involves
scanning the deployed application
for known security weaknesses
that can be exploited by attackers.
Runtime Application Self-Protection is a security technology
that operates within
the Post-Deployment Runtime environment.
It provides real-time protection
by monitoring application behavior
and blocking threats on observed anomalies.
For example, after deploying
a new online banking application,
the bank's Runtime Application Self-Protection tool
may identify an attempted Structured Query Language
or SQL injection attack.
In response, the Runtime Application Self-Protection tool
can automatically block malicious requests,
preventing unauthorized access.
This real-time defense mechanism helps mitigate threats
that could be exploited
despite having static security measures in place.
After that, we will look at
Continuous Integration/Continuous Deployment Management.
Continuous Integration/Continuous Deployment Management
involves automating the process of integrating code changes,
running tests, and deploying applications
which ensure consistent and efficient software delivery.
Continuous Integration/Continuous Deployment
Management concepts
include coding standards and linting, branch protection,
and continuous improvement.
Coding standards and the use of a linting tool
ensure the code adheres to predefined guidelines.
This improves readability
and reduces the risk of introducing security vulnerabilities
or bugs to the software.
Branch Protection involves setting up rules
that control how code changes are merged
into important development branches.
Branch Protection may require code reviews
and automated testing before branch integration.
Continuous Improvement includes
regularly updating and refining
the Continuous Integration/Continuous Deployment pipeline
based on feedback and performance metrics.
Putting these concepts together,
a development team might enforce coding standards
and use a linting tool to identify potential security issues
before code is merged into the main branch
of the version control system.
They will also use Branch Protection
to ensure only reviewed and tested code is deployed
and continuously improve
the Continuous Integration/Continuous Deployment pipeline
by incorporating new security tools and practices
based on the latest threats and vulnerabilities.
Next, we will explore
the Continuous Integration/Continuous Deployment
Testing process.
Continuous Integration/Continuous Deployment testing
systematically evaluates code changes
to identify and address security vulnerabilities
and functional issues
before the code is deployed to production.
Continuous Integration/Continuous Deployment
testing concepts include
Canary Testing, Regression Testing,
Automated Test and Test, Unit Testing,
and Integration Testing.
Canary Testing involves deploying changes
to a small subset of users to monitor for issues
before a full rollout.
In this manner, Canary Testing helps detect
potential security flaws quickly.
Next, Regression Testing ensures new code changes
do not adversely affect existing functionality.
Then, Integration Testing may be used to check
the interaction between different system components,
which identifies issues arising from combined functionality.
Additionally, Automated Test and Retest processes
streamline the identification of bugs and vulnerabilities
by running tests automatically
during the Continuous Integration/Continuous Deployment
testing pipeline.
Finally, Unit Testing focuses on verifying
individual components or functions for correctness.
Last, we will look at End-of-Life or EOL considerations.
End-of-Life considerations involve planning and managing
the security implications of decommissioning or replacing
software and hardware.
Specific End-of-Life considerations
include lifecycle management and data migration.
Lifecycle management ensures
that unsupported software or hardware
is either upgraded or replaced
to avoid exposure to unpatched vulnerabilities.
Data migration and secure deletion practices
must be implemented to protect sensitive information
from unauthorized access during transition.
For example, when decommissioning an old server,
an organization should migrate data
to a new supported system
and securely wipe the old server storage
to prevent data breaches.
To finish things off, we'll take a short quiz
to see what you learned during this section of the course,
and we will review each of those quiz questions fully,
to ensure you can explain why the right answers were right
and the wrong answers were wrong.
So, let's get ready to dive into Security in Systems
in this section of the course!