1. Assurance, Trust and Confidence Mechanisms
1.1. Integrity
1.1.1. procedures to compare or reconcile what was processed against what was supposed to be processed
1.1.2. check if the right operation was performed on the right data
1.1.3. Examples
1.1.3.1. totals
1.1.3.2. check sequence numbers
1.2. Accuracy
1.2.1. data validation
1.2.2. verification checks
1.2.3. examples
1.2.3.1. character ckecks
1.2.3.1.1. input characters against expected type of characters
1.2.3.2. range checks
1.2.3.2.1. input data against predetermined uppoer and lower limits
1.2.3.3. relationship checks
1.2.3.3.1. input data against data on a master record file
1.2.3.4. reasonableness check
1.2.3.4.1. input data against expected standard
1.2.3.5. transaction limits check
1.2.3.5.1. input data against administratively set ceilings on specified transactions
1.3. Auditing
1.3.1. what types of unauthorized activities have taken place and who or what processes took the action
1.4. ECA
1.4.1. Evaluation
1.4.2. Certification
1.4.3. Accreditation
2. Security Technology and Tools
2.1. SDLC
2.1.1. System Feasibility
2.1.1.1. Information Security Policy
2.1.1.2. Standards
2.1.1.3. Legal Issues
2.1.1.4. Early Validation of concepts
2.1.2. Software Plans & Requirements
2.1.2.1. Threats
2.1.2.2. Vulnerabilities
2.1.2.3. Security Requirements
2.1.2.4. Reasonable Care
2.1.2.5. Due Diligence
2.1.2.6. Legal Liabilities
2.1.2.7. Cost/Benefits Analysis
2.1.2.8. Level of protection desired
2.1.2.9. Develop test plans
2.1.2.10. Validation
2.1.3. Product Design
2.1.3.1. Incorporate Security Specifications
2.1.3.2. Adjust Test Plans and Data
2.1.3.3. Determine Access Controls
2.1.3.4. Design Documentation
2.1.3.5. Evaluate Encryption Options
2.1.3.6. Verification
2.1.4. Detailed Design
2.1.4.1. Design Security Controls Commensaturate with legal requirements
2.1.4.2. Design Access Controls
2.1.4.3. Employ Encryption
2.1.4.4. Adapt Security Test Plans
2.1.4.5. Detailed Documentation Design
2.1.4.6. Consider Business Continuity Issues
2.1.4.7. Finalize User GUI
2.1.4.8. Verification
2.1.5. Coding
2.1.5.1. Develop information security-related code
2.1.5.2. Implement Unit Testing
2.1.5.3. Incorporate other modules or units
2.1.5.4. Support business continuity plan
2.1.5.5. Develop documentation
2.1.6. Integration Product
2.1.6.1. Integrate Security Components
2.1.6.2. Test integrated modules
2.1.6.3. Refine Documentation
2.1.6.4. Conduct Security Related product verification
2.1.7. Implementation
2.1.7.1. Install Security Software
2.1.7.2. Run systems
2.1.7.3. Conduct Acceptance Testing
2.1.7.4. Test Security Software
2.1.7.5. Complete Documentation, certification and accreditation
2.1.8. Operations & Maintenance
2.1.8.1. Revalidate Security Controls
2.1.8.2. Conduct Penetration testing and vulnerability analysis
2.1.8.3. Manage Request for Changes
2.1.8.4. Implement change control
2.1.8.5. Deliver changes
2.1.8.6. Evaluate conformance to SLA and validations
2.1.8.7. Update documentation, recertification
2.2. Software Development Methods
2.3. Security in Systems Development Methods (SDM)
2.3.1. Project initiation and planning
2.3.1.1. Identify User Needs
2.3.1.1.1. Identify Security Needs
2.3.1.2. Evaluate Alternatives
2.3.1.2.1. Initial Risk Analysis
2.3.1.3. Select / Approve Approach
2.3.1.3.1. Identify Security Framework
2.3.2. Functional Requirement Definition
2.3.2.1. Prepare project plan
2.3.2.1.1. Security areas in project plan
2.3.2.2. Develop functional requirements
2.3.2.2.1. Define security requirements
2.3.2.3. Preliminary test plan
2.3.2.3.1. Preliminary security test plan
2.3.2.4. Select acquisition strategy
2.3.2.4.1. Include security requirements in RFP and contracts
2.3.2.5. Establish formal functional baseline
2.3.2.5.1. Functional baseline has security requirements
2.3.3. System Design Specification
2.3.3.1. Develop detailed design
2.3.3.1.1. Define security specifications
2.3.3.2. Update testing goals and plans
2.3.3.2.1. Update security test plan
2.3.3.3. Establish formal baseline / quality controls and requirements
2.3.3.3.1. Include security area in formal baseline documentation and quality assurance
2.3.4. Build / Development and Documentation
2.3.4.1. Construct source code from detailed design specification
2.3.4.1.1. Write or procure and install security-related code
2.3.4.2. Perform and evaluate unit tests
2.3.4.2.1. Perform unit test and evaluate security-related code
2.3.4.3. Implement detailed design into final system
2.3.4.3.1. Ensure approved security components in formal baseline are included
2.3.5. Documentation and Common program controls
2.3.5.1. Program / application
2.3.5.1.1. Operating instructions / procedures
2.3.5.1.2. Utilities
2.3.5.1.3. Privileged functions
2.3.5.2. Job and system docs
2.3.5.2.1. Compontents
2.3.5.2.2. Restart and recovery procedures
2.3.5.3. Common program controls
2.3.5.3.1. Edits
2.3.5.4. Logs
2.3.5.4.1. Who, what, when
2.3.5.4.2. Timestamps
2.3.5.4.3. Before and after images
2.3.5.5. Counts
2.3.5.5.1. for process integrity checks
2.3.5.5.2. total transactions
2.3.5.5.3. batch totals
2.3.5.5.4. hash totals
2.3.5.5.5. balances
2.3.5.6. Internal checks
2.3.5.6.1. checks for data integrity
2.3.5.6.2. from when the program gets the data to when it is done with the data
2.3.5.6.3. Parameter ranges and data types
2.3.5.6.4. Valid and legal address references
2.3.5.6.5. Completion codes
2.3.5.7. Code Peer review
2.3.5.8. Program or data library when developing software applications
2.3.5.8.1. Automated control system
2.3.5.8.2. Current versions
2.3.5.8.3. Record of changes made
2.3.5.9. Erroneous / invalid transactions
2.3.5.9.1. when detected are writeen to a report and reviewed by developes and management
2.3.6. Acceptance
2.3.6.1. Test system components
2.3.6.1.1. Test security components
2.3.6.2. Validate system performance
2.3.6.2.1. Test security in integrated system
2.3.6.3. Install system
2.3.6.3.1. Install security code with necessary modifications
2.3.6.4. Prepare project manuals
2.3.6.4.1. Document security controls
2.3.6.5. Perform acceptance test
2.3.6.5.1. Conduct acceptance test
2.3.6.6. Accept system
2.3.6.6.1. Accept / verify project security
2.3.7. Testing and Evaluation Controls
2.3.7.1. Guidelines for environment
2.3.7.1.1. type of data
2.3.7.1.2. test with known good data
2.3.7.1.3. data validation before and after each test
2.3.7.1.4. bounds checking
2.3.7.1.5. sanitize test data
2.3.7.1.6. Test data should not be production data until preparing for final UAT
2.3.7.2. Testing controls
2.3.7.2.1. test all changes
2.3.7.2.2. management acknowledges the results of the test
2.3.7.2.3. Program librarian retains implementation test data
2.3.7.2.4. Parallel run requires a separate copy of production data
2.3.7.3. http://www.kb.cert.org/vuls
2.3.8. Certification and Acreditation
2.3.8.1. process of evaluating
2.3.8.1.1. the security stance of the software
2.3.8.1.2. system against a predetermined set of security standards
2.3.8.1.3. how well the system performs its intended functional requirements
2.3.8.2. should be documented
2.3.8.2.1. analysis of the technical and nontechnical security features and countermeasures
2.3.8.2.2. that the extent that the system meets the security requirements for its mission and operational environment
2.3.8.3. Certifying officer
2.3.8.3.1. verifies that the software has been tested
2.3.8.3.2. verifies that the system meets all applicable policies, regulations, standards for securing information systems
2.3.8.4. Accreditation officer
2.3.8.4.1. reviews the certification
2.3.8.4.2. authorizes the system to be implemented in a production
2.3.8.5. Accreditation
2.3.8.5.1. provisional
2.3.8.5.2. full
2.3.9. Transition to Production (Implementation)
2.3.9.1. System is transitioned from the acceptance phase to the live production environment
2.3.9.2. activities
2.3.9.2.1. obtaining security accreditation
2.3.9.2.2. training the new users according to schedules
2.3.9.2.3. implementing the system
2.3.9.3. security activites
2.3.9.3.1. verifiy that the data conversion and data entry are controlled and only privileged users have access
2.3.9.3.2. acceptable level of risk is determined
2.3.9.3.3. security accreditation is obtained
2.3.9.3.4. controls in place to reconcile and validate the accuracy do information after it is entered into the system
2.3.10. Operations and Maintenance Support (Post-Installation)
2.3.10.1. operations activities
2.3.10.1.1. monitoring the performance of the system
2.3.10.1.2. ensuring continuity of operations
2.3.10.1.3. detecting defects or weaknesses
2.3.10.1.4. managing and preventing system problems
2.3.10.1.5. recovering from system problems
2.3.10.1.6. implementing system changes
2.3.10.2. operations security activities
2.3.10.2.1. testing backup
2.3.10.2.2. testing recovery procedures
2.3.10.2.3. ensuring proper controls for data
2.3.10.2.4. report handling
2.3.10.2.5. effectiveness of security processes
2.3.10.3. maintenance security activities
2.3.10.3.1. significant changes
2.3.10.4. common activities
2.3.10.4.1. verify that any changes to procedures of functionality do not disable or circumvent the security features
2.3.10.4.2. verify compliance with applicable SLAs according to the initial operational and security baselines
2.3.11. Revisions and System Replacement
2.3.11.1. hardware and software baselines should be subject to periodic evaluations and audits
2.3.11.2. any changes must follow the same SDM and be recorded in a change management system
2.3.11.3. reviews should include security planning and procedures to aviod future problems
2.3.11.4. documenting security incidents when problems occur
2.4. Programming Languages and security
2.5. Assemblers, Compilers and Interpreters
2.6. Software Protection Mechanisms
2.7. DBMS Controls
2.7.1. Lock Controls
2.7.1.1. Page locking
2.7.1.2. Table locking
2.7.1.3. Row locking
2.7.1.4. Field locking
2.7.1.5. ACID test
2.7.1.5.1. Atomicity
2.7.1.5.2. Consistency
2.7.1.5.3. Isolation
2.7.1.5.4. Durability
2.7.2. Access Controls
2.7.2.1. Discretionary Access Controls (DACs)
2.7.2.2. Mandatory Access Controls (MACs)
2.7.2.3. Access Matrix
2.7.2.4. View-Based Access Controls
2.7.2.4.1. MAC
2.7.2.4.2. appropriate use and manipulation of views
2.7.2.4.3. DB logically devided into pieces
2.7.2.4.4. controls must be in place to restrict user from bypassing the front end and directly access data
2.7.2.4.5. View allows the restriction
2.7.2.5. Grant and Revoke Access Controls
2.7.2.5.1. if a user is granted access without the grant option, the user should not be able to pass grant authority to other users
2.7.2.5.2. User may copy the relation and subvert the system, then grant access to the copy despite he wasn't owner of the relation
2.7.2.5.3. cascading efect in revoke statement - all users who may have been granted access by the newly revoked user will be revoked too
2.7.3. Security for OO DBs
2.7.3.1. Problem
2.7.3.1.1. Most of models have been designed for relational DBs
2.7.3.1.2. Security models for OO DBs are complex
2.7.3.1.3. Models differ in their capabilities and protections
2.7.3.2. ORION
2.7.3.2.1. Explicit Authorizations
2.7.3.2.2. The authorization model that provides DACs
2.7.3.2.3. Positive authorization
2.7.3.2.4. Negative authorization
2.7.3.2.5. Implicit authorizations
2.7.3.2.6. SORION MACs
2.7.3.3. SODA
2.7.3.3.1. Secure Object-Oriented Database model
2.7.3.3.2. Dr. Thomas Keefe
2.7.3.3.3. standard example of secure OO models
2.7.3.3.4. MAC properties and can be executed in systems operating at a multi-level
2.7.3.3.5. classification levels
2.7.3.3.6. Multi-party update conflict
2.7.3.3.7. the system becomes a collection of several distinct database systems, each with its own data.
2.7.3.4. Metadata Controls
2.7.3.4.1. Goal
2.7.3.4.2. Security controls
2.7.3.5. Data Contamination Controls
2.7.3.5.1. Goal
2.7.3.5.2. Security controls
2.7.3.6. OLTP
2.7.3.6.1. Online Transaction Processing
2.7.3.6.2. Detect when individual processes abort
2.7.3.6.3. Automatically restart an aborted process
2.7.3.6.4. Back out of a transaction if necessary
2.7.3.6.5. Allow distribution of multiple copies of application servers across machines
2.7.3.6.6. Perform dynamic load balancing
2.7.3.7. Knowledge Management
2.7.3.7.1. Approaches
2.7.3.7.2. Security controls
3. Information Protection Environment
3.1. Open- and ClosedSource Code
3.2. Software Environment
3.2.1. Threats to the Software Environment
3.2.1.1. Buffer Overflow
3.2.1.2. Citizen Programmers
3.2.1.3. Covert Channel
3.2.1.4. Malicious Code /Malware
3.2.1.4.1. Virus
3.2.1.4.2. File infector virus
3.2.1.4.3. Boot sector infector
3.2.1.4.4. System infector
3.2.1.4.5. Multipartie virus
3.2.1.4.6. E-mail virus
3.2.1.4.7. Macro virus
3.2.1.4.8. Script virus
3.2.1.4.9. Worms
3.2.1.4.10. Trojan horses
3.2.1.4.11. Remote Access Trojan
3.2.1.4.12. Bomb
3.2.1.4.13. Data diddler
3.2.1.4.14. Hoax
3.2.1.4.15. Pranks
3.2.1.5. Memory/Object Reuse
3.2.1.6. Executable Content / Modile Code
3.2.1.7. Social Engineering
3.2.1.8. Time of Check / Time of Use
3.2.1.9. Trapdoor / Backdoor
3.3. DB and DWH Environment
3.3.1. duplicated data of the same entity in the past, often inconsistent as not updated concurrently
3.3.2. information replicated in several files on a system has been replaced by databases which inporporated the information from multiple sources
3.3.3. to integrate and manage the data required for several applications into a common storage area
3.4. DBMS Architecture
3.5. DB Interface Languages
3.6. SAML
3.7. Datawarehousing
3.7.1. Process of building DWH
3.7.1.1. Feed all data into a large, high-availability, and high-integrity database that resides at the confidentiality level of the most sensitive data
3.7.1.2. Normalize the data. Regardless of how the data is characterized in each system, it must be structured the same when moved into the data warehouse.
3.7.1.2.1. For example, one database could categorize birthdate as “month/date/year,” another as “date/month/year,” and still another as “year/month/date.” The data warehouse must “normalize” the various data categories into only one category.
3.7.1.2.2. Normalization will also remove redundancies in the data.
3.7.1.3. Mine the data for correlations to produce metadata.
3.7.1.4. Sanitize and export the metadata to its intended users.
3.7.1.5. Feed all new incoming data and the metadata into the data warehouse.
3.7.2. Metadata
3.7.2.1. Information about the data
3.7.2.2. Provides a systemativ method for describing resources and improving the retrieval of information
3.7.2.3. provides valuable information about the unseen relationships between data and the ability to correlate data previously considered unrelated.
3.7.2.4. Dublin Core Metadata Initiative (DCMI) standard
3.7.2.5. Data are accessed through Online Analytical Processing (OLAP) or Knowledge-Discovery in Databases (KDD) methods
3.7.3. OLAP
3.7.3.1. provides ability to formulate queries and, based on the outcome of the queries, to define further queries
3.7.4. Data Mining
3.7.4.1. another tool in addition to OLAP
3.7.4.2. process of discovering information in DWH by running queries on the data
3.7.4.3. Used to reveal hidden relationships, patterns and trends
3.7.4.4. Decision making technics based on a series of analytical techniques taken from mathematics, statistics, cybernetics and genetics
3.7.4.5. Advantages
3.7.4.5.1. ability to provide better info to managers
3.7.4.5.2. tools to review audit logs for intrusion attempts
3.7.4.5.3. helps to discover abnormal events
3.7.4.6. Disadvantages
3.7.4.6.1. detailed data about individuals might risk a violation of privacy
3.7.4.6.2. integrity may be at risk, as human data entry may not be accurate (relationships or patterns)
3.8. DB Vulnerabilities and Threats
3.8.1. Aggregation
3.8.1.1. combined unclassified data from separate resources result in sensitive information
3.8.2. Bypass attacks
3.8.2.1. bypass controls at the front end
3.8.2.2. bypass the query engine
3.8.3. Compromising DB views used for Access Control
3.8.3.1. access to restricted views or modification of an existing view
3.8.4. Concurrency
3.8.4.1. running process that use old data
3.8.4.2. running process that updates that are inconsistent
3.8.4.3. running process having a deadlock occur
3.8.5. Data contamination
3.8.5.1. data integrity corruption by input dara errors or erroneous processing
3.8.5.2. file, report, DB
3.8.6. Deadlocking
3.8.6.1. when 2 users attempts the same information and both are denied
3.8.7. DoS
3.8.7.1. poorly designed application
3.8.7.2. query that locks up the table and requires intensive processing
3.8.8. Improper modification of information
3.8.8.1. unauthorized users intentionaly
3.8.8.2. authorized users accidentally
3.8.9. Inference
3.8.9.1. ability to deduce (infer) information from observing available information
3.8.9.2. list of patients and their medicines -> what ilness they have
3.8.10. Interception of data
3.8.10.1. in dial-up and remote access
3.8.10.2. interception of the sesstion
3.8.11. Polyinstantiation
3.8.11.1. information stored in more than one location in the DB
3.8.11.2. multiple levels-of-view and authorization
3.8.11.3. must be effective method for simultaneously updating all occurrences of the same data element
3.8.12. Query attacs
3.8.12.1. query tools to access data normally not alloweb by the trusted front end
3.8.13. Server access
3.8.13.1. protection from unauthorized logical access
3.8.13.2. control from unauthorized physical access
3.8.14. TOC/TOU
3.8.14.1. malicious code could change data between the time that the user's quesry was approved and the time the data is displayed to the user
3.8.15. Web security
3.8.16. Unauthorized access
4. My Geistesblitzes
4.1. Cissp
5. OOP
5.1. Potentially capable of being more reliable and reduces the possible propagation of program change errors
5.2. Items
5.2.1. Classess
5.2.1.1. These tell the system how to make objects, the process of creating an object using directions in a class is called "instantiation"
5.2.2. Objects
5.2.2.1. Objects contatin procedures
5.2.2.1.1. Called methods
5.2.2.1.2. Data called attributes
5.2.2.2. Often called black box functions
5.2.2.2.1. happen, but cannot see
5.2.3. Messages
5.2.3.1. Objects perform work by sending messages to other objects
5.3. Fundamental characteristics
5.3.1. Encapsulation
5.3.1.1. Data hiding
5.3.2. Polymorphism
5.3.2.1. Different objects can react to identical messages in different ways
5.3.3. Polyinstantiation
5.3.3.1. Allows an object to be copied and populated with different data
5.3.4. Inheritance
5.3.4.1. Subclassess inherit settings
5.3.5. All predefined types are objects
5.3.6. All user defined types are objects
5.3.7. All operations are performed by sending messages to objects
5.4. Distributed systems
5.4.1. CORBA
5.4.1.1. Common Object Request Broker Architecture
5.4.2. DCOM
5.4.2.1. Distributed Component Object Model
5.5. ORB
5.5.1. Object Request Brokers
5.5.2. Made available to users over a network
5.5.3. Middleware
5.5.4. Establishes a client-server relationship between objects
6. CBK
6.1. What CISSP should know
6.1.1. Security and controls of the systems development process, application controls, change controls, data warehousing, data mining, knowledgebased systems, program interfaces, and concepts used to ensure dataand application integrity, confidentiality, and availability
6.1.2. The security and controls that should be included within systems and application software
6.1.3. The steps and security controls in the software life cycle and change control process
6.1.4. Concepts used to ensure data and software integrity, confidentiality, and availability
6.1.5. Computer viruses and other forms of malicious code, including ActiveX and Java
6.1.6. How malicious code can be introduced into the computing environment
6.1.7. Mechanisms that can be used to prevent, detect, and correct malicious code and their attacks
6.2. Components
6.2.1. Application Issues
6.2.2. Distributed Environment
6.2.2.1. Agents
6.2.2.2. Applets
6.2.2.3. ActiveX
6.2.2.4. Java
6.2.2.5. Objects
6.2.3. Local/Non-distributed Environment Attacks
6.2.3.1. Viruses
6.2.3.2. Trojan Horses
6.2.3.3. Logic Bombs
6.2.3.4. Worms
6.2.4. Databases and Data Warehousing
6.2.4.1. Aggregation
6.2.4.2. Data Mining
6.2.4.3. Inference
6.2.4.4. Polyinstantiation
6.2.4.5. Multi-Level Security
6.2.5. DBMS Architecture
6.2.6. Knowledge-based Systems
6.2.6.1. Expert Systems
6.2.6.2. Neural Networks
6.2.7. Systems Development Controls
6.2.8. System Development Life Cycle
6.2.8.1. Requirements Determination
6.2.8.2. Protection Specifications Development
6.2.8.3. Design Review
6.2.8.4. System Test Review
6.2.8.5. Certification and Accreditation
6.2.8.6. Maintenance
6.2.8.7. Service Level Agreement
6.2.9. Malicious code
6.2.9.1. Definitions
6.2.9.2. Jargon
6.2.9.3. Myths/Hoaxes
6.2.10. Attackers
6.2.10.1. hackers
6.2.10.2. crackers
6.2.10.3. phreaks
6.2.10.4. virus writers
6.2.11. Anti-viral protection, Anti-viral software
6.2.12. Various types of computer viruses
6.2.13. Methods of attack
6.2.13.1. Trapdoors
6.2.13.2. Brute-Force
6.2.13.3. Denial-of-Service
6.2.13.4. Dictionary attacks
6.2.13.5. Spoofing
6.2.13.6. Pseudo Flaw
6.2.13.7. Alteration of authorized code
6.2.13.8. Flooding
6.2.13.9. Cramming
6.3. Questions
6.3.1. Define the A-I-C triad as it relates to application security.
6.3.2. Define programming-related aggregation.
6.3.3. Define security-related aggregation.
6.3.4. Define and describe applet as it refers to IT/IS.
6.3.5. Define architectural neural distribution format (ANDF).
6.3.6. Describe artificial neural network (ANN).
6.3.7. Define “backdoor” as related to IT/IS.
6.3.8. Define Common Object Request Broker Architecture (CORBA).
6.3.9. Compare and contrast input controls, output controls, and transaction controls.
6.3.10. Define covert channel, covert storage channel, and covert timing channel.
6.3.11. Define data contamination.
6.3.12. Define data integrity.
6.3.13. Define data mining.
6.3.14. Define distributed systems environment.
6.3.15. Define encapsulation as related to IT/IS.
6.3.16. Define file protection.
6.3.17. Define garbage collection.
6.3.18. Define granularity as related to IT/IS.
6.3.19. Describe potential types of malicious code threats.
6.3.20. Define logic bomb.
6.3.21. Define neural network.
6.3.22. Define Object Linkage and Embedding (OLE).
6.3.23. Define object-oriented design (OOD).
6.3.24. Define object-oriented programming (OOP).
6.3.25. Define polyinstantiation.
6.3.26. Define polymorphism.
6.3.27. Define scalability as it refers to IT/IS.
6.3.28. Compare and contrast trapdoors, Trojan horses, and worms as related to IT/IS.
6.3.29. Distinguish between various IT/IS-related threats and attacks.
6.3.30. Identify system lifecycle phases.
6.3.31. Describe functional design analysis and planning.
6.3.32. Compare and contrast project design activities and parallel security activities.
6.3.33. Describe system design specifications.
6.3.34. Compare and contrast project test activities and parallel security activities.
6.3.35. Identify maintenance support/operations in relation to IT/IS.
6.3.36. Define development methodology controls.
6.3.37. Define object-oriented technology.
6.3.38. Describe object request brokers (ORBs).
6.3.39. Define object-oriented techniques.
6.3.40. Describe the benefits of object-oriented programming (OOP).
6.3.41. Describe methods of object-oriented programming (OOP).
6.3.42. Define the distinguishing features of object-oriented programming (OOP).