Reading...
Play button
Play button
Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
142 Cards in this Set
- Front
- Back
|
Holistic Security |
Holistic Security is the first & foremost software security concept, It is pivotal to recognize that software is only as secure as the weakest link |
|
|
Iron Triangle Constraints
|
Resources (scope), cost (budget) & time (schedule). Resources (people) with appropriate skills are not always readily available. Software development in & of itself is a resource, schedule (time) & budget intensive process.
|
|
|
Security as an Afterthought
|
Developers & management tend to think that security does not add any business value since it is not very easy to show a one to one return on security investment.
|
|
|
Security vs. Usability
|
The incorporation of secure features is viewed as rendering the software to become very complex, restrictive & unusable.
|
|
|
Confidentiality
|
Confidentiality is the security concept that has to do with protection against unauthorized information disclosure. Not only does confidentiality assure the secrecy of data but it also can help in maintaining data privacy.
|
|
|
Integrity
|
Integrity is the measure of software resiliency & it has to do with the alternation or modification of data & the reliable functioning of software.
|
|
|
Availability
|
Availability is the security concept that is related to the access of the software or the data or information it handles.
|
|
|
Authentication
|
Authentication is a security concept that answers the question, 'Are you whom you claim to be?' It not only ensures that the identity of an entity (person or resource), but it also validates or verifies the identity information that has been supplied.
|
|
|
Authentiction Factors
|
Knowledge:The identifying information provided in this mechanism for validation is something that one knows.Ownership:The identifying information provided in this mechanism for validation is something that you own or have.Characteristic:The identifying information provided in this mechanism for validation is something you are.
|
|
|
Authorization
|
Authorization is the security concept in which access to objects is controlled based on the rights & privileges that are granted to the requestor by the owner of the data or system or according to a policy
|
|
|
Auditing
|
Auditing is the security concept in which privileged & critical businesses transactions are logged & tracked.Auditing is a passive detective control mechanism. Auditing is a detective control & it can be a deterrent control as well.
|
|
|
Non repudiation
|
Non repudiation addresses the deniability of actions taken by either a user or the software on behalf of the user
|
|
|
Accountability
|
Accountability to ensure non repudiation can be accomplished by auditing when used in conjunction with identification.
|
|
|
Least Privilege
|
A security principle in which a person or process is given only the minimum level of access rights (privileges) that is necessary for that person or process to complete an assigned operation
|
|
|
Separation of Duties (or) Compartmentalization Principle
|
Separation of duties is a security principle which states that the successful completion of a single task is dependent upon two or more conditions that need to be met & just one of the conditions will be insufficient in completing the task by itself.
|
|
|
Defense in Depth (or) Layered Defense
|
Defense in depth is a security principle where single points of complete compromise are eliminated or mitigated by the incorporation of a series or multiple layers of security safeguards & risk mitigation countermeasures.
|
|
|
Fail Secure
|
A security principle that aims to maintaining confidentiality, integrity & availability by defaulting to a secure state, rapid recovery of software resiliency upon design or implementation failure
|
|
|
Economy of Mechanisms
|
Keep It Simple principle because the likelihood of a greater number of vulnerabilities increases with the complexity of the software architectural design & code. By keeping the software design & implementation details simple, the attackability or attack surface of the software is reduced.
|
|
|
Complete Mediation
|
A security principle that ensures that authority is not circumvented in subsequent requests of an object by a subject, by checking for authorization (rights & privileges) upon every request for the object
|
|
|
Open Design
|
The open design security principle states that the implementation details of the design should be independent of the design itself, which can remain open, unlike in the case of security by obscurity wherein the security of the software is dependent upon the obscuring of the design itself.
|
|
|
Least Common Mechanisms
|
The security principle of least common mechanisms disallows the sharing of mechanisms that are common to more than one user or process if the users & processes are at different levels of privilege
|
|
|
Psychological Acceptability
|
A security principle that aims at maximizing the usage & adoption of the security functionality in the software by ensuring that the security functionality is easy to use & at the same time transparent to the user.
|
|
|
Weakest Link
|
This security principle states that the resiliency of your software against hacker attempts will depend heavily on the protection of its weakest components, be it the code, service or an interface.
|
|
|
Leveraging Existing Components
|
This is a security principle that focuses on ensuring that the attack surface is not increased & no new vulnerabilities are introduced by promoting the reuse of existing software components, code & functionality.
|
|
|
Risk Management
|
Risk management is the balancing act between the protection of IT assets & the cost of implementing software security controls, so that the risk is handled appropriately.The processes include the preliminary assessment for the need of security controls, the identification, development, testing, implementation & verification (evaluation) of security controls so that the impact of any disruptive processes are at an acceptable or risk appropriate level.
|
|
|
Asset
|
Assets are those items that are valuable to the organization, the loss of which can potentially cause disruptions in the organization’s ability to accomplish its missions.
|
|
|
Vulnerability
|
A weakness or flaw that could be accidently triggered or intentionally exploited by an attacker, resulting in the breach or breakdown of the security policy is known as a vulnerability
|
|
|
Threat
|
Vulnerabilities pose threats to assets. A threat is merely the possibility of an unwanted, unintended or harmful event occurring. When the event occurs upon manifestation of the threat, it results in an incident.
|
|
|
Threat Source/Agent
|
Anyone or anything that has the potential to make a threat materialize is known as the threat source or threat agent
|
|
|
Attack
|
When the threatagent actively & intentionally causes a threat to happen, it is referred to as an ‘attack’ & the threat agents are commonly referred to as ‘attackers
|
|
|
Probability
|
Also known as ‘likelihood’, probability is the chance that a particular threat can happen
|
|
|
Impact
|
The extent of how serious the disruptions to the organization’s ability to achieve its goal is referred to as the impact.
|
|
|
Exposure Factor
|
Exposure Factor is defined as the opportunity for a threat to cause loss. Exposure Factor plays an important role in the computation of risk.
|
|
|
Security Controls
|
Security controls are mechanisms by which threats to software & systems can be mitigated.
|
|
|
Total Risk
|
Total risk is the likelihood of the occurrence of an unwanted, unintended or harmful event
|
|
|
Residual Risk
|
Residual risk is the risk that remains after the implementation of mitigating security controls (countermeasures or safeguards).
|
|
|
Single Loss Expectancy (SLE)
|
It is used to estimate potential loss.SLE = Asset Value ($) x Exposure Factor (%)
|
|
|
Annual Rate of Occurrence (ARO)
|
It is an expression of the number of incidents from a particular threat that can be expected in a year.
|
|
|
Annual Loss Expectancy (ALE)
|
It is an indicator of the magnitude of risk in a year. ALE is a product of SLE x ARO
|
|
|
Risk Management challenges in Software
|
Software risk management is still maturing, Determination of software asset values is often subjective, Data on the exposure factor, impact, & probability of software security breaches is lacking or limited, Technical security risk is only a portion of the overall state of secure software.
|
|
|
Handling Risk by Management
|
Ignore the risk, Avoid the risk, Mitigate the risk, Accept the risk, Transfer the risk
|
|
|
Security Policies
|
It is the instrument by which digital assets that require protection can be identified. It also includes identifying the organization’s goals & objectives, ensures non repudiation, provide guidance to architect secure software & define the functions & scope of the security team.
|
|
|
Scope of organizational Security Policies
|
is universally applicable & all who are part of the organization must comply with it
|
|
|
Scope of Functional Security Policies
|
is limited to a specific functional unit or a specific issue.
|
|
|
SP 800 12: An Introduction to Computer Security:The NIST Handbook
|
This handbook provides a broad overview of computer security, providing guidance to secure hardware, software & information resources.It explains computer security related concepts, cost considerations & inter relationships of security controls
|
|
|
SP 800 14: Generally Accepted Principles & Practices for Security IT Systems
|
SP 800 14 document provides a baseline that organizations can use to establish & review their IT security programs. This document gives insight into the basic security requirements that most IT systems should contain, to various stakeholders, including management, internal auditors, users, system developers & security practitioners.
|
|
|
SP 800 18: Guide for developing Security Plans for Federal Systems
|
The SP 800 18 provides a framework for developing relevant security plans. It contains within a framework for classifying information assets based on impact to the three core security objectives
|
|
|
SP 800 27: Engineering Principles for Information Technology Security
|
Provides various IT security principles as listed. Some of these principles are people oriented, while others are tied to the process for designing security in IT systems.
|
|
|
SP 800 30: Risk Management Guide for IT
|
It describes a comprehensive risk assessment methodology which includes nine primary steps for conducting a risk assessment of an IT system. It also covers control categories, cost benefit analysis, residual risk evaluation, and the mitigation options and steps that need to be taken upon the completion of a risk assessment process.
|
|
|
SP 800 61: Computer Security Incident Handling Guide
|
Assists organizations in establishing capabilities and incident handling procedures to efficiently and effectively handle security threats and breaches that are prevalent and evident today. It is useful for both established and newly formed incident response teams
|
|
|
SP 800 64: Security Considerations in the Information Systems Development Life Cycle
|
It provides guidance for building security into the IT systems (or software) development life cycle (SDLC) from the inception of the system or software
|
|
|
SP 800 100: Information Security Handbook: A Guide for Managers
|
While this is a must read for management professional who are responsible for establishing and implementing an information security program, it can also benefit non management personnel as it provides guidance from a management perspective |
|
|
FIPS
|
FIPS publications are developed to address Federal requirements for interoperability of disparate systems, portability of data and software and Computer security
|
|
|
FIPS 140: Security Requirement for Cryptographic Modules
|
The FIPS 140 is the standard that specifies requirements that will need to be satisfied by a cryptographic module. It provides four increasing qualitative levels (Level 1 through Level 4) intended to cover a wide range of potential application and environments.
|
|
|
FIPS 186: Digital Signature Standard (DSS)
|
FIPS 186: Digital Signature Standard (DSS) specifies a suite of algorithms that can be used to generate a digital signature.The DSS prescribes guidelines for digital signature generation, verification and validation.
|
|
|
FIPS 197: Advanced Encryption Standard
|
FIPS 197: Advanced Encryption Security (AES) specifies an approved cryptographic algorithm to ensure the confidentiality of electronic data.This standard replaced the withdrawn FIPS 46 3 Data Encryption Standard (DES) that prescribed the need to use one of the two algorithms, DES or Triple Data Encryption Algorithm (TDEA) for data protection.
|
|
|
FIPS 201: Personal Identity Verification (PIV) of Federal Employees and Contractors
|
The FIPS 201 Personal Identity Verification (PIV) standard was developed in response to the need to ensure that the claimed identity of personnel (employees and contractors) who require physical or electronic access to secure and sensitive facilities and data are appropriately verified.
|
|
|
ISO/IEC 15408–Evaluating Criteria for IT Security (Common Criteria)
|
The ISO/IEC 15408 is more commonly known as the Common Criteria and is a series of internationally recognized set of guidelines that define a common framework for evaluating security features and capabilities of Information Technology security products
|
|
|
ISO/IEC 15408 1:2005
|
Introduces the common criteria providing the evaluation criteria for IT security as it pertains to security functional requirements and security assurance requirements. It introduces the general model that covers the Protection Profile (PP), the Security Target (ST) and the Target of Evaluation (TOE) and the relationships between these elements of the Common Criteria evaluation process.
|
|
|
ISO/IEC 15408 2:2008
|
Contains the comprehensive catalog of predefined security functional requirements (SFRs) that needs to be part of the security evaluation against the TOE
|
|
|
ISO/IEC 15408 3:2008
|
Defines the security assurance requirements (SARs) and includes the evaluation assurance levels (EALs) for measuring assurance of a TOE. There are seven EAL ratings predefined in Part 3 of the ISO/IEC 15408 standards and a security product with a higher EAL rating is indicative of a greater degree of security assurance for that product against comparable products with a lower EAL rating.
|
|
|
The ISO/IEC 15408 Standard and Software Security
|
The predefined SFRs and SARs defined in the ISO/IEC 15408 standard can be used to address vulnerabilities that arise from failures in Requirements, Development and/or in Operations. Software that does not include security functional or assurance requirements can be rendered ineffective and insecure even if meets all business functionality
|
|
|
ISO/IEC 21827:2008 Systems Security Engineering Capability Maturity Model (SSE CMM)
|
The SSE CMM internationally recognized standard provides guidelines to ensure secure engineering of systems (and software) by augmenting existing project and organizational process areas and encompassing all phases in the SDLC in its scope from concepts definition, requirement analysis, design, development, testing, deployment, operations, maintenance, and disposal.
|
|
|
ISO/IEC 25000:2005 Software Engineering Product Quality
|
The ISO/IEC 25000:2005 provides recommendations and prescriptive guidance for the use of the new series of International quality standards named Software product Quality Requirements and Evaluation (SQuaRE).
|
|
|
ISO/IEC 27000:2009 Information Security Management System (ISMS) Overview and Vocabulary
|
This standard aims to provide a common Glossary of Terms and definitions. It also provides an overview and introduction to the ISMS family of standards covering requirements definition for an ISMS, detailed guidance to interpret the Plan Do Check Act (PDCA) processes, sector specific guidelines and conformity assessments for ISMS
|
|
|
ISO/IEC 27001:2005 Information Security Management Systems Requirements
|
What the ISO 9001:2000 standards do for quality, the ISO 27001:2005 standard will do for information security. It specifies the requirements for establishing,implementing, operating, monitoring, reviewing, maintaining and improving a documented ISMS.
|
|
|
ISO/IEC 27002:2005/Cor1:2007 Code of Practice for Information Security Management
|
This standard establishes guidelines and general principles for initiating, implementing, maintaining, and improving information security management in an organization. It is a replacement for the ISO 17799 standard which was formerly known as BS 7799.
|
|
|
ISO/IEC 27005:2008 Information Security Risk Management
|
This standard provides the necessary guidance for information security risk management and is designed to assist the implementation of security control to a satisfactory level based on establishing the scope or context for risk assessment, assessing the risks, making risk based decisions to treat the identified risks, and communicating and monitoring risk.
|
|
|
ISO/IEC 27006:2007 Requirements for Bodies Providing Audit and Certification of Information Security Management Systems
|
This primary goal of this standard is to support accreditation and certification bodies that audit and certify information security management systems. It includes in it the competency and reliability requirements that an auditing and certifying body must demonstrate and also provides guidance on how to interpret the requirements it contains to ensure reliable and consistent certification of Information Security Management Systems.
|
|
|
ISO 28000:2007 Specification for security management systems for the supply chain
|
specifies the requirements for a security management system, including those aspects critical to security assurance of the supply chain.
|
|
|
Payment Card Industry Data Security Standard (PCI DSS)
|
is a set of comprehensive requirements aimed at increasing payment account data security.The goal of the PCI DSS is to facilitate organization’s efforts to proactively protect card holder payment account data.
|
|
|
PCI DSS Requirement 1
|
Install and maintain a firewall configuration to protect cardholder data
|
|
|
PCI DSS Requirement 2
|
Do not use vendor supplied defaults for system passwords & other security parameters
|
|
|
PCI DSS Requirement 3
|
Protect stored cardholder data
|
|
|
PCI DSS Requirement 4
|
Encrypt transmission of cardholder data across open, public networks
|
|
|
PCI DSS Requirement 5
|
Use and regularly update anti virus software
|
|
|
PCI DSS Requirement 6
|
Develop and maintain secure systems and applications
|
|
|
PCI DSS Requirement 7
|
Restrict access to cardholder data by business need to know
|
|
|
PCI DSS Requirement 8
|
Assign a unique ID to each person with computer access
|
|
|
PCI DSS Requirement 9
|
Restrict physical access to cardholder data
|
|
|
PCI DSS Requirement 10
|
Track and monitor all access to network resources and cardholder data
|
|
|
PCI DSS Requirement 11
|
Regularly test security systems and processes
|
|
|
PCI DSS Requirement 12
|
Maintain a policy that addresses information security
|
|
|
PCI DSS Requirement 6.1
|
Ensure that all system components and software have the latest vendor supplied security patches installed. Install critical security patches within one month of release.
|
|
|
PCI DSS Requirement 6.2
|
Establish a process to identify newly discovered security vulnerabilities (e.g., alert subscriptions) and update configuration standards to address new vulnerability issues.
|
|
|
PCI DSS Requirement 6.3
|
Develop software applications in accordance with industry best practices (e.g., input validation, secure error handling, secure authentication, secure cryptography, secure communications, logging, etc.), and incorporate information security throughout the software development life cycle
|
|
|
PCI DSS Requirement 6.4
|
Follow change control procedures for all changes to system components.
|
|
|
PCI DSS Requirement 6.5
|
Develop all web applications based on secure coding guidelines (such as OWASP) to cover common coding vulnerabilities in software development
|
|
|
PCI DSS Requirement 6.6
|
For public facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either reviewing these applications annually or upon change, using manual or automated security assessment tools or methods, or by installing a web application firewall in front of the public facing web application.
|
|
|
Payment Application Data Security Standard
|
It assist Qualified Security Assessors (QSAs) when conducting payment application reviews. QSAs can use the PA DSS to validate that their payment application that they are assessing is compliant with the PCI DSS, because it serves as a template to create the report on validation. It used to be formerly known as the Payment Application Best Practices (PABP).
|
|
|
Organization for the Advancement of Structured Information Standards (OASIS)
|
The Organization for the Advancement of Structured Information Standards (OASIS) consortium drives the development, convergence and adoption of open standards for the global information society. It promotes industry consensus and produces standards for security, Cloud computing, Service Oriented Architectures (SOA), Web services, the Smart Grid, etc.
|
|
|
Standards published by OASIS
|
Application Vulnerability Description Language (AVDL), Security Assertion Markup Language (SAML), eXtensible Access Control Markup Language (XACML), Key Management Interoperability Protocol (KMIP) Specification, Universal Description, Discovery and Integration (UDDI), Web Services (WS*) Security |
|
|
Benefits of Security Standards
|
Security standards provide a common and consistent basis for building and maintaining secure software as they enable operational efficiency and organizational agility. |
|
|
ITIL
|
ITIL v3 that considers the Lifecycle of a service from initial planning, alignment to business need to final retirement, unlike its previous versions which were process focused. ITIL V3 was revised to be aligned with industry best practices and standards and aptly covers existing Information Security standards, such as those in the ISO 27000 series. |
|
|
Software development Methodologies
|
The Software Development Lifecycle (SDLC) is often broken down into multiple phases that are either sequential or parallel. The prevalent SDLC models that are used Waterfall model, Iterative model, Spiral model, Agile development methodologies.
|
|
|
Waterfall Model
|
It is a highly structured, linear & sequentially phased process characterized by predefined phases, each of which must be completed before one can move on to the next phase.
|
|
|
Iterative Model
|
In the iterative model of software development, the project is broken into smaller versions & developed incrementally.This allows the development effort to be aligned with the business requirements, uncovering any important issues early in the project & therefore avoiding disastrous faulty assumptions.
|
|
|
The spiral model
|
is a software development model that has elements of both the waterfall model & the prototyping model, generally for larger projects. The key characteristic of this model is that each phase has a risk assessment review activity.
|
|
|
Agile Development Methodologies
|
The agile development methodologies are built on the foundation of iterative development with the goal of minimizing software development project failure rates by developing the software in multiple repetitions (iterations) & small timeframes (called timeboxes).
|
|
|
Extreme Progrmming (Agile) model
|
The XP model is also referred to as the “people centric” model of programming & is useful for smaller projects. It is a structured process as depicted storyboards & architects user requirements in iterations & validates the requirements using acceptance testing.
|
|
|
Scrum (Agile) model
|
In Scrum methodology, the software is kept in a constant state of readiness for release. The participants in Scrum have pre defined roles, which are of two types depending on their level of commitment.
|
|
|
Software Assurance Methodologies
|
There are several software assurance methodologies that aid in the design, development, testing & deployment of quality & secure software. These range from simple methodologies to those more robust & comprehensive that can be used at different stages of the SDLC.
|
|
|
Socratic Methodology
|
The Socratic methodology is a useful technique for addressing issues that arise from individuals who have opposing views on the need for security in the software they build. It is a form of cross examination & is also known as the Method of Elenchus whose goal is to instigate ideas & stimulate rational thought.
|
|
|
Six Sigma
|
Sigma is a business management strategy for quality it can be closely related to security because it is used for process improvement by measuring if a software or service is near perfect in quality by eliminating defects. For a process to be certified as having Six Sigma quality, it must have at the maximum 3.4 defects per million opportunities (DPMO) where an opportunity is defined as a chance for deviation (or non conformance) to specifications.
|
|
|
DMAIC (Define, Measure, Analyze, Improve & Control) (Six Sigma)
|
which is used for incremental improvement of existing processes that are below Six Sigma quality
|
|
|
DMADV (Define, Measure, Analyze, Design & Verify) (Six Sigma)
|
which is used to develop new processes for Six Sigma products & services. It can also be used for new versions of the product or service when the extent of changes are substantially greater than what incremental improvements can address.
|
|
|
Capability Maturity Model Integration (CMMI)
|
The Capability Maturity Model Integration (CMMI) is a process improvement methodology as well, which provides guidance for quality improvement & point of reference for appraising existing processes. It is a 1 5 rating scale that can be used to rate the maturity of the software development processes within one’s organization.
|
|
|
Operationally Critical Threat, Asset & Vulnerability Evaluation (OCTAVE)
|
which is a risk based information security strategic assessment methodology.
|
|
|
Open Source Security Testing Methodology Manual (OSSTMM)
|
which is a peer reviewed testing methodology for conducting security tests & how to measure the results using applicable metrics. Output from OSSTMM security audit is a report known as Security Test Audit Report (STAR), which includes the specific actions conducted in tests, the corresponding metrics & the state of the strength of controls.
|
|
|
Flaw Hypothesis Method (FHM)
|
The Flaw Hypothesis Method (FHM) is as the name suggests a vulnerability prediction & analysis method that uses comprehensive penetration testing to test the strength of the security of the software. FHM is very useful in the area of software certification.
|
|
|
Zachman Framework
|
The goal of the framework is to align Information Technology to the business. It is often depicted as a 6 x 6 matrix that factors in 6 reification transformations (strategist, owner, designer, builder, implementer, & workers) along the rows & 6 communication interrogatives (what, how, where, who, when & why) as columns. The intersection of the six transformations & the six interrogatives yield the architectural elements. Using the same interrogative technique in security stand point can be useful to determine the security needs.
|
|
|
Control Objectives for Information & related Technology (COBIT)
|
is an IT governance framework with supporting tools that can be used to close gaps between control requirements, technical issues & business risks.
|
|
|
Committee of Sponsoring Organizations (COSO)
|
COSO is a conglomeration of worldwide recognized frameworks that provides guidance on organizational governance, business ethics, internal controls, enterprise risk management, fraud & financial reporting.
|
|
|
Sherwood Applied Business Security Architecture (SABSA)
|
SABSA is a framework for developing risk based enterprise security architectures & for delivering security solutions that support business initiatives. It is based on the premise that security requirements are determined from the analysis of the business requirements.
|
|
|
Sarbanes Oxley Act (SOX)
|
The Sarbanes Oxley Act, commonly referred to as SOX is arguably the most significant of regulations that has a direct impact on security.The SOX Act has 11 titles that mandate specific requirements for financial reporting & address
|
|
|
BASEL II
|
BASEL II is the European Financial Regulatory Act that was originally developed to protect against financial operations risks & fraud. It was developed initially to be an international standard for banking regulators & provide recommendations on banking regulations & laws.
|
|
|
Gramm Leach Bliley Act (GLB Act)
|
The Gramm Leach Bliley Act (GLB Act) is a financial privacy act that aims to protect consumers’ personal financial information (PFI) contained in financial institutions. It is also known as the Financial Modernization Act of 1999.
|
|
|
Financial Privacy rule (GLB ACT)
|
which governs the collection & disclosure of PFI. Inclusive in its scope are companies that are non financial in nature as well.
|
|
|
Safeguards Rule(GLB ACT)
|
applies only to financial institutions & mandates that these institutions design, implement & maintain safeguards to protect customer information.
|
|
|
Pretexting Provisions (GLB ACT)
|
of this Act provide protection to consumers from individuals & companies who falsely pretend (pretext) a need to obtain PFI.
|
|
|
Health Insurance Portability & Accountability Act (HIPAA)
|
This is another privacy rule but unlike the GLB Act that deals with personal financial information (PFI), the Health Insurance Portability & Accountability Act (HIPAA) deals with personal health information (PHI).
|
|
|
Data Protection Act
|
was enacted to regulate the collection, processing, holding, using & disclosure of an individual’s private or personal information. Software that collects, processes, stores & archives personal data must, therefore, be designed & developed with deletion or de identification mechanisms.
|
|
|
Computer Misuse Act
|
This act makes provisions for securing computer material against unauthorized access and/or modification. Computer misuse such as hacking, unauthorized access, unauthorized modification of contents, & disruptive activities like the introduction of viruses are designated as criminal offenses.
|
|
|
Mobile Device Privacy Act
|
The Mobile Device Privacy Act would require mobile device sellers, manufacturers, service providers, & app offerors to disclose to consumers the existence of any monitoring software.the bill would require any entity subject to the requirements above to obtain express consumer consent before the monitoring software collects any information.
|
|
|
State Security Breach Laws
|
The California civil code 1798.82 which was the harbinger of its kind.This requires that personal information be destroyed when it is no longer needed by the collecting entity.
|
|
|
Challenges with Regulatory Mandates
|
The challenges that organizations face when they need to comply with regulations & privacy mandates are open interpretations, auditor’s subjectivity, localized jurisdiction, regional variations, & inconsistent enforcement.
|
|
|
Best practice guidelines for data privacy
|
If you don’t need it, don’t collect it. If you need to collect it for processing only, collect it only after you have informed the user that you are collecting their information & they have consented, but don’t store it.If you have the need to collect it for processing & storage, then collect it, with user consent, & store it only for an explicit retention period that is compliant with organizational policy & regulatory requirements. Also dont archive it.
|
|
|
Data Anonymization
|
Anonymization is the process of removing private information from the data. Anonymized data cannot be linked to any one individual account.
|
|
|
Replacement (Anonymization technique)
|
is the anonymization technique in which identifiable information is substituted with non identifiable information. For example, the primary account number of a cardholder is replaced by dummy data.
|
|
|
Suppression (Anonymization technique)
|
is the anonymization technique in which identifiable information is omitted from the information being released. For example, only the last four number of the individual’s social security number is maintained.
|
|
|
Generalization (Anonymization technique)
|
is the anonymization technique in which specific identifiable information is replaced using a more generalized form. For example, the date of birth information is replaced by just the year of birth
|
|
|
Pertubation (Anonymization technique)
|
also known as randomization, is the anonymization technique that involves making random changes to the data.
|
|
|
Disposition
|
Most privacy regulations requires the implementation of policies & procedures to address final disposition of private information. For electronic media, overwriting (using software or hardware products to format media), degaussing (exposing the media to a strong magnetic field in order to disrupt the recorded magnetic domains), or destroying the media are the methods for disposition
|
|
|
Security Models
|
It is a formal presentation of the security policy. Security models include the sequence of steps that are required to develop secure software or systems & provide the ‘blueprint’ for the implementation of security policies. Security models can be broadly categorized into confidentiality models, integrity models, & access control models.
|
|
|
Trusted Computing
|
is ensuring software assurance & in the context of the CSSLP, we focus primarily on software security assurance.There are certain concepts 1 must be familiar with in regards. These are Ring Protection, Trust Boundary, Trusted Computing Base (TCB) & Reference Monitor.
|
|
|
Ring Protection
|
Ring protection mechanism can be portrayed as a set of concentric numbered rings.The lower the ring level the higher the level of access & vice versa.
|
|
|
Trust Boundary (or Security Perimeter)
|
(TCB) is the abstract concept that ensures that the security policy is enforced at all times. It is an abstract concept in the sense that software architects & designers must take into account all the hardware, software & firmware components & their mechanisms to design secure software.
|
|
|
Process Activation (TCB)
|
It is extremely important for the TCB to ensure that the activation of processes is not circumvented & sabotaged by a malicious process that can result in a compromise with undesirable effects.
|
|
|
Execution Domain Switching (TCB)
|
Each process & its set of data values must be isolated from other processes & the TCB must ensure that one process executing at a particular domain cannot switch to another domain that requires a different level of trust for operations to continue & complete, i.e., switching from low trust user land to highly privileged kernel land & back is not allowed.
|
|
|
Memory Protection (TCB)
|
The TCB monitors memory references to ensure that disclosure, alteration (contamination) & destruction of memory contents is disallowed.
|
|
|
Input/Output (I/O) operations (TCB)
|
The TCB ensures that the sequence of cross domain communications for access to I/O devices does not violate the security policy.
|
|
|
Reference Monitor
|
A subject’s access to an object must be mediated & allowed based on the subject’s privilege level. This access is mediated by what is commonly known to as the Reference Monitor. The reference monitor is an abstract concept that enforces or mediates access relationships between subjects & objects. |
