Information Security Notes PDF

INFORMATION SECURITY Definitions ​ “Information is an asset to all individuals and businesses” ○​ Asset = it has value ​ Information Security refers to the protection of these assets in order to achieve CIA (Confidentiality, Integrity, and Availability) ​ “Informati...

INFORMATION SECURITY Definitions ​ “Information is an asset to all individuals and businesses” ○​ Asset = it has value ​ Information Security refers to the protection of these assets in order to achieve CIA (Confidentiality, Integrity, and Availability) ​ “Information security refers to the processes and methodologies which are designed and implemented to protect print, electronic, or any other form of confidential private and sensitive information or data from unauthorized access, use, misuse, disclosure, destruction, modification, or disruption” - SANS Institute. CIA (Confidentiality, Integrity, and Availability) ​ Confidentiality ○​ Information kept private and secure ○​ Assurance that information is available only to those authorized to have access ​ You have to know which entities have access to your information ○​ Risk: loss of privacy, unauthorized access to information, and identity theft ○​ Control: encryption (only the receiver has access to open the file), authentication (right credentials) , access control ​ Integrity ○​ Data not modified, deleted, or added ○​ Trustworthiness of data or resources ○​ Safeguard the accuracy and completeness of information and processes methods ○​ Risk: information is no longer reliable or accurate and fraud ○​ Control: quality assurance and audit logs (monitoring changes) ​ Availability ○​ Systems available to whom requires them ○​ Assurance that systems for processing, delivering and storing information are accessible when required ○​ Risk: business disruption, loss of customer confidence and loss of revenue ○​ Control: back-up storage and sufficient capacity AAA (Authentication, Authorization, and Audit Trail) ​ The Triple A of Information Security ​ Supporting concepts required to implement the CIA in practice ​ Technology-centric, varies according to the technologies used/present ○​ How do you make users aware of phishing emails? ​ Authentication  ○​ The act in which subject attempts to verify/prove their claims to a given identity ○​ 3 primary forms: ​ What you know ​ Piece of information that is only known by you ideally ​ Passwords, PINs, and Passphrases are a few common examples of this authentication mechanism ​ What you have ​ Devices that contain specific data or generate data that validates a subjects identity ​ Proximity cards, RSA Tokens, Certificate Keys ​ Something tangible and owner has it ○​ Multi-factor authentication, authenticator app ​ What you are ​ Biological traits that are specific and unique enough to identify an individual ​ Finger print, palm print, iris patterns ​ Authorization ○​ The act of granting an authenticated subject the proper access rights to different assets ○​ Only takes place after authentication ○​ Common authorization schemes: ​ Mandatory Access Control ​ Discretionary Access Control ​ Attribute-based Access Control ○​ For example, MLS will only give permissions (functions) (for student or for professor) after you log in ​ Audit Trails ○​ Security controls are useless unless specific activities can be tracked ○​ Errors, Login attempts, changes, etc should all be tracked and stored in a secure location ○​ Actions should be traceable to a specific subject to allow information to be useful Key Concepts ​ Assets ○​ Any item, tangible or intangible, with value to an organization ​ Intangible: friendship with friends, etc. ○​ An asset is anything whose loss can potentially cause disruption to an organization ​ Vulnerabilities ○​ A weakness or flaw that may be accidentally or intentionally triggered leading to the violation of security policies  ​ Example: if web application has no secured system, anyone can enter the web application ○​ May be present in the inherent design or the implementation of the actual system ○​ Several vulnerability tracking systems exist: ​ US Computer Emergency Readiness Team ​ Common Vulnerability Scoring System ​ Ranks the vulnerabilities you have found ​ Common Vulnerabilities and Exposure ​ Threats, Impact, Exposure Factor ○​ Threat: is an action or event that may potentially compromise or violate security ​ Malicious or Incidental ○​ Incident: is the occurrence upon realization of a violation of security ○​ Impact: is the outcome when a violation of security has been realized ○​ Exposure factor: is defined as the potential loss of an asset when a threat is realized ​ Risk ○​ The probability that a particular threat directed towards a specific vulnerability will occur ○​ Risk management refers to the process reducing risks to acceptable levels ○​ Note: there is no such thing as zero risk ​ Security Controls (Countermeasures) ○​ Mechanisms by which threats can be mitigated ○​ Divided into 3 groups: ​ Technical ​ Administrative ​ Physical ○​ Improper implementations may even increase risk Software Engineering ​ The process of solving customers’ problems by the systematic development and evolution of large, high-quality software systems withing cost, time and other constraints ​ Challenges ○​ Lack of understanding of user needs ○​ Unclear scope ○​ Lack of change management ○​ Poor project planning ○​ Communication problems ○​ Teamwork problems ○​ Security issues Software Development Life Cycles  ​ A sequence of steps that are performed when building software products ​ Sequences/steps vary depending on model ​ Life cycles have evolved over time in response to changing technology and user needs Basic Life Cycle Phases ​ Requirement Phase ​ Analysis Phase ​ Design Phase ​ Implementation Phase ​ Post-delivery maintenance ​ Retirement SDLC Models ​ Code-andFix ​ Waterfall ​ Interactive ​ Incremental ​ Agile ​ Scrum Model-View-Controller ​ A software architecture ideally suited to web applications ​ Separates the logic from the user interface ​ Allows individual components to be tested independently of one another ​ In terms of security, provides extra layer of protection through isolation Model ​ Encapsulated functionality and represents data in a structured manner ​ Provides an abstraction between low level primitives and the Controller and View ​ At this level, data being received and sent should be checked against business rules in place ​ Java classes that represent Users, Books, Authors View ​ Also called the presentation layer, the view provides users a frontend with which to interact with which to interact with ​ This level renders data into HTML and should not contain any business logic ​ Data collected from this is sent back to the controller ​ Java Server Pages that display results of user queries  ​ Controller ​ Contains the application or business logic needed to process user data ​ This acts as the mediator between the Model and the View ​ Apart from processing, it should contain code needed to protect the application from threats ​ Java Servlets that pass collect and process data from the users Security Principles ​ Principles and practices applications should adhere to in order to remain secure ​ Should be adapted based on the needs of the current project ​ Applies not only to web applications but to IT systems as a whole Principles ​ Minimize attack surface area ​ Secure defaults ​ Principle of least privilege ​ Principle of defense in depth ​ Fail securely ​ External Systems are insecure ​ Separation of duties ​ Security through obscurity is not security ​ Simplicity ​ Fix issues correctly Secure Coding Principles Characteristics of Secure Organizations ​ Organizational management with security champions ​ Proper information security policies ​ Development methodologies with security checkpoints ​ Secure release and configuration management Development Methodology Selection ​ Strong acceptance of design, testing, and documentation ​ Security controls can be easily introduced ​ Matches the organization’s size and maturity  ​ Reduces error rate and improves performance Coding Standards ​ Architectural requirements ​ Documentation requirements ​ Testing requirements ​ In-code commenting ​ Exception handling ​ Naming conventions THREAT MODELING Evaluation Methodologies Manual Inspection and Review ​ Human-driven review that analyzes the impact of people, policies, and processes to security ​ Focused on analyzing existing artifacts and interviewing individuals ​ Has the ability to test the SDLC as a whole ​ “Trust-but-verify” ​ Pros ○​ Requires no supporting technology ○​ Flexible ○​ Encourages teamwork ○​ Can be applies early in the SDLC ​ Cons ○​ Time consuming ○​ Needed artifacts are sometimes missing ○​ High level of human skills and thought Penetration Testing ​ The ‘art; of testing deployed applications remotely without knowledge of its working ​ A staple of network security testing ​ Uses tools and manual techniques to verify the security of an application ​ Pros ○​ Fast and cheap ○​ Relatively lower skill-set required ○​ Tests code in production ​ Cons ○​ Late in the SDLC ○​ Impact testing only Source Code Review ​ Manual checking of the source code for problems  ​ Provides reviewers with a lot more information than other approaches ​ Serious vulnerabilities missed, are seen in code ​ Requires more effort (time) than other techniques ​ Pros ○​ Complete and effective ○​ Accurate ○​ Fast ​ Cons ○​ High level of skill ○​ Compiled libraries are not covered ○​ Run-time errors may be missed ○​ Actual code vs. reviewed code Introduction to Threat Modeling Threat ​ Potential or actual undesirable event that may be malicious or incidental ​ Malicious → DoS attack ​ Incidental → failure of a storage device Threat Model ​ A structured representation of all information that affects the security of an application ​ A view of the application and its environment through security glasses Threat Modeling ​ A process for capturing, organizing, and analyzing information that affects the security of an application ​ Enables informed decision-making about application security risk ​ In addition to producing a model, typical threat modeling efforts also produce a prioritized list of security improvements to the concept, requirements, design, or implementation ​ Pros ○​ Attacker’s PoV ○​ Flexible ○​ Early in the SDLC ​ Cons ○​ New technique ○​ Good threat Model is not equal to Good Software Objectives of Threat Modeling ​ A procedure of optimizing Network/ Application/ Internet Security by identifying objectives and vulnerabilities ​ Defining countermeasures to prevent, or mitigate the effects of, threats to the system Benefits of Threat Modeling  ​ Provides a clear “line of sight” across a project that justifies security efforts ​ Allows security decisions to be made rationally ​ Produces an assuage argument that can be used to explain and defend the security of an application ​ An assurance argument starts with a few high level claims, and justifies them with either sub claims or evidence Prerequisites ​ Clearly designed security policies ​ Awareness of compliance and regulatory requirements ​ Mature SDLC process ​ Will actually use the threat model Threat Modeling in SDLC ​ A high-level threat model should be defined in the concept or planning phase and then refined throughout the lifecycle ​ As more details are added to the system, new attack vectors are created and exposed ​ Ongoing threat modeling process should examine, diagnose, and address these threats ​ A natural part of refining a system for new threats to be exposed ​ Example:​ ○​ Is using Java, you take on the responsibility to identify the new threats that are created by that choice ○​ Even implementation choices such as using regular expressions for validation introduce potential new threats to deal with Threat Modeling: Generic Steps ​ To understand whether an application is secure enough or not, you have to search out combinations of these ingredients that lead to realistic threats ​ The real trick to threat modeling is not wasting time on threats that are too unlikely or too inconsquential ​ There is no “right” way to evaluate the search space of possible threats, but there are “wrong” ways ​ Attempting to or evaluating all the possible combinations of threat agent, attack, vulnerability, and the impact is a waste of time and effort ​ It is more productive to focus on finding high-likelihood and high impact threats Assessment Scope ​ Identifying tangible assets, like databases of information or sensitive files is usually easy ​ Understanding the capabilities provided by the application and valuing them is more difficult ​ Less concrete things, such as reputation and goodwill are the most difficult to measure, but are often the most critical Identifying Threat Agents ​ A key part of the threat model is characterization of the different groups of people who might be able to attack your application ​ These groups should include insiders and outsiders, performing both inadvertent mistakes and malicious attacks Understanding Existing Countermeasures ​ The model must include the existing countermeasures Identifying Exploitable Vulnerabilities ​ Once you have an understanding of the security application, you can then analyze for new vulnerabilities ​ The search is for vulnerabilities that connect the possible attacks you’ve identifies to the negative consequences you’ve identified Prioritize Identified Risks ​ Prioritization is everything in threat modeling, as there are always lots of risks that simple don’t rate any attention ​ For each threat, you estimate number of likelihood and impact factors to determine an overall risk or severity level Identify Countermeasures to Reduce Threats ​ The last step is to identify countermeasures to reduce the risk to acceptable levels Stride / Dread Model ​ Developed by Microsoft and suggested by the OWASP for use  ​ Provides a classification scheme for known threats and the likelihood of realization ​ Inherently built for use with applications ​ Simply to use and deploy ​ Developing a thorough model may be difficult at first for inexperienced users Stride Dread ​ Spoofing identity ​ Damage Potential ​ Tampering with Data ​ Repudiation ​ Information Disclosure ​ Denial of Service ​ Elevation of Privilege ​ Reproducibility ​ Exploitability ​ Affected Users ​ Discoverability Performing Threat Modeling ​ Define 1.​ Identify security objectives and assets 2.​ Profile application ​ Model 3.​ Decompose the application 4.​ Identify threats and vulnerabilities ​ Measure 5.​ Document the threats 6.​ Prioritize the threats Identify Security Objectives ​ Prior to any action, the direction of an organization in terms of security should be understood ​ Ideally, this should be performed by business leadership, development team, and the QA team ​ Consider the following: ○​ Identity ○​ Financial Reputation ○​ Privacy and Regulatory Availability Application Profiling ​ Provides a high-level view of the application and its components ​ Achieved through the analysis of an application;s architecture and design documents ​ The following artifacts may help: ○​ Class Diagrams ○​ ERD Diagrams ○​ Data Flow Diagrams ○​ Use Case Diagrams ​ Points to consider: ○​ Physical topology ○​ Logical topology ○​ Components, services, protocols ○​ Actors  ○​ Data elements ○​ Access control matric ○​ Technologies ○​ Eternal dependencies Decompose the Application ​ From the top, drill down to specific components for analysis ​ Identify features, behaviors, adn requirements that can impact security given how the application functions ​ Tasks ○​ Identify Trust Boundaries ○​ Identify Entry Points ○​ Identify Exit Points ○​ Identify Data Flow ○​ Identify Privileged Code ○​ Document Secuirty Profile Identify Threats ​ Once a thorough understanding of the application is achieved, specific threats to the application should be identified ​ Focus should be known threats ​ Tracking threats: ○​ Threat Graph ○​ Structured Threat List ​ Common Threats ○​ Ignorant User ○​ Accidental Discoverer ○​ Curious Attacker ○​ Script Kiddies ○​ Insider ○​ Organized Crime ○​ ** STRIDE may be used to classify threats based on the intent Threat Graph ​ Pleaces developers in the mindset of an attacker ​ Brainstorming possible threat scenarios ​ Represented as a tree: ○​ Root - attacker’s objective/attack type ○​ Child Node - vulnerability ○​ Bottom Ndoe - security control ​ References ○​ OWASP Top 10  ○​ Sans Top 25 Threat List ​ Goal-based approach to threat modeling ​ More structured than the threat graph ​ Can show cross-correlation between different threats ​ Possible with: ○​ STRIDE ○​ OCTAVE ○​ NSA IAM Identifying Attack Surfaces ​ Attack surfaces are areas in an application that may be levered for an attack ​ Howard, Pincus, and Wing identified 3 dimensions: ○​ Targets and Enablers ○​ Channels and Protocols ○​ Access Rights  Document Threats ​ All outputs from the previous steps should be recorded due to the iterative nature of threat modeling ​ Diagram vs. Text ​ A standard template should be used to ensure consistency ○​ Threat Identifier ○​ Description ○​ Targets ○​ Attack Techniques ○​ Impact ○​ Risk Prioritize Threats ​ Threat modeling to assist in decision making ​ Prioritizing the threats identifies helps development teams identify and rank which to tackl first ​ Common Approaches ○​ Delphi Ranking ○​ Average Ranking (DREAD) ○​ Probability x Impact Ranking Average Ranking Probability x Impact Ranking ​ A more scientific approach to computing for risk ​ Typical in Risk Management calculations ​ Organizations use the following  SECURITY CODING PRINCIPLES Characteristics of Secure Organizations ​ Organizational management with security champions ○​ Data Protection Officer, Incident Response team ​ Proper information security policies ​ Development methodologies with security checkpoints ​ Secure release and configuration management Development Methodology Selection ​ Strong acceptance of design, testing, and documentation ○​ These make sure your software is functional and secure ​ Security controls can be easily introduced ○​ During the design or development phase ​ Matches the organization’s size and maturity ​ Reduces error rate and improves performance Requirements and Coding Standards Architectural Requirements  ​ Define how the system should be designed to meet security, performance and compliance goals ○​ Not only about functionality ​ Key aspects ○​ Security - enforce authentication, encryption, and secure communication (other security protocols for software) ○​ Scalability - support increasing users and data without performance degradation ○​ Modularity - ensure components are loosely coupled for easier maintenance (components can be updated and modified, easy to put back together) ○​ Reliability - prevent single points of failure through redundancy and fault tolerance ○​ Compliance - follow industry standards (ex. GDPR, HIPAA, PCI DSS) Documentation Requirements ​ Necessary guidelines, records, and reports that ensure security is integrated throughout the software development lifecycle (SDLC) ○​ Gives a detailed history of what needs to be accomplished and what has been accomplished ​ Ensures transparency, compliance, and maintainability in software development ​ Covers security policies, system design, coding standards, threat modeling, testing, and incident response ​ Helps developers, auditors, and security teams understand and enforce security measure Testing Requirements ​ Security testing methodologies, tools, and best practices that ensure web applications have minimal vulnerabilities and comply with security standards ​ Security testing is important to identify vulnerabilities before attackers do ​ A combination of SAST, DAST, pen testing, and fuzz testing provides comprehensive coverage ○​ Pen testing - ethical hackers, utilize different tools to compromise the application ○​ Fuzz testing - trying different input data ​ Authentication, access control, and secure configurations must be validated to prevent common attacks ​ Regulatory compliance (ex. GDPR, OWASP ASVS, PCI DSS) must be tested to avoid legal risks In-Code Commenting ​ Practice adding descriptive, security-aware comments within the source code to enhance readability, maintainability, and security awareness ​ Helps developers understand security implementation, potential risk, and important security measures within the codebase ​ Best practices: ○​ Explain security mechanisms to improve developer understanding ○​ Warn about potential security risks in critical areas ○​ Avoid storing secrets in comments to prevent leaks  ​ Avoid putting usernames, passwords, keys, etc. ○​ Use comments to enforce-secure coding guidelines and best practices ○​ Keeps comments accurate and update to reflect security improvements Exception Handling ​ Gracefully managing errors and unexpected conditions in an application while ensuring security, stability, and minimal exposure or sensitive information to attackers ○​ Ex. asking input from user, instead of giving a number they give a character or string ​ Application should remain secure ​ Proper exception handling helps prevent information leaks, denial-of-service (DoS) attacks, and unauthorized access ​ Things to remember when implementing: ○​ Hide detailed error messages from users to prevent information leaks ​ “Username or Password is wrong” ○​ Use custom error pages instead of default web server error responses ​ You can customize how th e error will look in users end ○​ Catch specific exceptions to avoid unintended behavior ○​ Prevent crashes by validating inputs and handling unexpected errors ○​ Lof errors securely and monitor logs for security incidents Naming Conventions ​ Structured and consistent rules for naming variables, functions, files, and database elements to enhance code readability, maintainability, and security ​ Proper naming conventions reduce risks such as confusion, accidental exposure of sensitive data, and vulnerabilities from insecure identifiers ​ Best practices: ○​ Avoid exposing sensitive information in names ○​ Use consistent and meaningful naming conventions to improve maintainability ○​ Prevent predictable identifiers in sessions, files, and API routes ​ It cannot be brute forced ​ Tracebacks should not happen ○​ Follow secure naming for database tables and environment variables ○​ Never hardcode passwords, API keys or sensitive data in variables or file names