Domain 8. Chapter 20 Flashcards
Domain 8. Chapter 19
1. Introducing Systems Development Controls
1.1 Software Development
1.2 Systems Development Lifecycle
1.3 Lifecycle Models
1.4 Application Programming Interfaces
1.5 Software Testing
1.6 Service-Level Agreements
1.7 Third-Party Software Acquisition
2. Establishing Databases and Data Warehousing
2.1 Database Management System Architecture
2.2 Database Transactions
2.3 Security for Multilevel Databases
2.4 Open Database Connectivity
3. Storage Threats
4. Understanding Knowledge-Based Systems
4.1 Expert Systems
4.2 Machine Learning
4.3 Neural Networks
- Introducing Systems Development Controls
1.1 Software Development
1.1.1 Programming Languages
You might not know that several types of languages can be used simultaneously by the same system.
The instructions that a computer follows consist of a long series of binary digits in a language known as machine language.
Assembly language is a higher-level alternative that uses mnemonics to represent the basic instruction set of a CPU. A task as simple as adding two numbers together could take five or six lines of assembly code!
They prefer to use high-level languages, such as Python, C++, Ruby, R, Java, and Visual Basic.
Once programmers are ready to execute their programs, two options are available to them: compilation and interpretation.
Some languages (such as C, Java, and Fortran) are compiled languages. A compiler to convert source code from a higher-level language into an executable file designed for use on a specific operating system.
It’s not possible to directly view or modify the software instructions in an executable file. However, specialists in the field of reverse engineering may be able to reverse the compilation process with the assistance of tools known as decompilers and disassemblers.
Code protection techniques seek to either prevent or impede the use of decompilers and disassemblers through a variety of techniques. For example, obfuscation techniques seek to modify executables to make it more difficult to retrieve intelligible code from them.
In some cases, languages rely on runtime environments to allow the portable execution of code across different operating systems. The Java virtual machine (JVM) is a well-known example of this type of runtime. Users install the JVM runtime on their systems and may then rely on that runtime to execute compiled Java code.
Other languages (such as Python, R, JavaScript, and VBScript) are interpreted languages. When these languages are used, the programmer distributes the source code, which contains instructions in the higher-level language. When end users execute the program on their systems, that automatically triggers the use of an interpreter to execute the source code stored on the system. If the user opens the source code file, they’re able to view the original instructions written by the programmer.
Методы защиты кода направлены на предотвращение или затруднение использования декомпиляторов и дизассемблеров с помощью различных методов. Например, методы обфускации направлены на изменение исполняемых файлов, чтобы затруднить извлечение из них понятного кода.
1.1.2 Libraries
Developers often rely on shared software libraries that contain reusable code. Many of these libraries are available as open source projects, whereas others may be commercially sold or maintained internally by a company.
To protect against similar vulnerabilities, developers should be aware of the origins of their shared code and keep abreast of any security vulnerabilities that might be discovered in libraries that they use.
Чтобы защититься от подобных уязвимостей, разработчики должны знать происхождение своего общего кода и быть в курсе любых уязвимостей безопасности, которые могут быть обнаружены в библиотеках, которые они используют.
1.1.3 Development Toolsets
The integrated development environment (IDE). IDEs provide programmers with a single environment where they can write their code, test it, debug it, and compile it (if applicable).
1.1.4 Object-Oriented Programming
Many modern programming languages, such as C++, Java, and the .NET languages, support the concept of object-oriented programming (OOP).
You can think of it as a group of objects that can be requested to perform certain operations or exhibit certain behaviors.
Objects work together to provide a system’s functionality or capabilities. For example, a banking program might have three object classes that correspond to accounts, account holders, and employees, respectively. When a new account is added to the system, a new instance, or copy, of the appropriate object is created to contain the details of that account.
Each object in the OOP model has methods that correspond to specific actions that can be taken on the object. For example, the account object can have methods to add funds, deduct funds, close the account, and transfer ownership.
Here are some common object-oriented programming terms you might come across in your work:
- Message
- Method
- Behavior The results or output exhibited by an object is a behavior.
- Class A collection of the common methods from a set of objects that defines the behavior of those objects is a class.
- Instance Objects are instances of or examples of classes that contain their methods.
- Inheritance Inheritance occurs when methods from a class (parent or superclass) are inherited by another subclass (child) or object.
- Delegation Delegation is the forwarding of a request by an object to another object or delegate. An object delegates if it does not have a method to handle the message.
- Polymorphism A polymorphism is the characteristic of an object that allows it to respond with different behaviors to the same message or method because of changes in external conditions.
-Cohesion связанность Cohesion describes the strength of the relationship between the purposes of the methods within the same class. When all the methods have similar purposes, there is high cohesion, a desirable condition that promotes good software design principles. When the methods of a class have low cohesion, this is a sign that the system is not well designed.
- Coupling Связь Coupling is the level of interaction between objects. Lower coupling means less interaction. Lower coupling provides better software design because objects are more independent. Lower coupling is easier to troubleshoot and update. Objects that have low cohesion require lots of assistance from other objects to perform tasks and have high coupling.
1.1.5 Assurance
Assurance procedures are simply formalized processes by which trust is built into the lifecycle of a system. The Common Criteria provide a standardized approach to assurance used in government settings.
1.1.6 Avoiding and Mitigating System Failure
You can employ many methods to avoid failure, including using input validation and creating fail-secure or fail-open procedures.
1.1.6.1 Authentication and Session Management
The level of authentication required by an application should be tied directly to the level of sensitivity of that application.
In most cases, developers should seek to integrate their applications with the organization’s existing authentication systems. It is generally more secure to make use of an existing, hardened authentication system than to try to develop an authentication system for a specific application.
This includes ensuring that any cookies used for web session management be transmitted only over secure, encrypted channels and that the identifiers used in those cookies be long and randomly generated. Session tokens should expire after a specified period of time and require that the user reauthenticate.
1.1.6.2 Error Handling
Developers love detailed error messages for debugging.
Developers should disable detailed error messages (also known as debugging mode) on any servers and applications that are publicly accessible.
1.1.6.3 Logging
Applications should be configured to send detailed logging of errors and other security events to a centralized log repository for cybersecurity analysts.
The Open Web Application Security Project (OWASP) Secure Coding Practices suggest logging the following events:
Input validation failures
- Authentication attempts, especially failures
- Access control failures
- Tampering attempts Попытки взлома
- Use of invalid or expired session tokens
- Exceptions raised by the operating system or applications
- Use of administrative privileges
- Transport Layer Security (TLS) failures
- Cryptographic errors
1.1.6.4 Fail-Secure and Fail-Open
- The fail-secure failure state puts the system into a high level of security (and possibly even disables it entirely) until an administrator can diagnose the problem and restore the system to normal operation.
- The fail-open state allows users to bypass failed security controls, erring on the side of permissiveness.
1.2 Systems Development Lifecycle
These core activities are essential to the development of sound, secure systems:
- Conceptual definition
- Functional requirements determination
- Control specifications development
- Design review
- Coding
- Code review walk-through Пошаговое руководство по проверке кода
- System test review Обзор тестирования системы
- Maintenance and change management
1.2.1 Conceptual Definition
The conceptual definition phase of systems development involves creating the basic concept statement for a system. It’s a simple statement agreed on by all interested stakeholders (the developers, customers, and management) that states the purpose of the project as well as the general system requirements.
At this point in the process, designers commonly identify the classification(s) of data that will be processed by the system and the applicable handling requirements.
1.2.2 Functional Requirements Determination
In this phase, specific system functionalities are listed, and developers begin to think about how the parts of the system should interoperate to meet the functional requirements.
The three major characteristics of a functional requirement:
Input(s) The data provided to a function
Behavior The business logic describing what actions the system should take in response to different inputs
Output(s) The data provided from a function
1.2.3 Control Specifications Development Разработка технических характеристик управления
During the development of control specifications, you should analyze the system from a number of security perspectives.
1)First, adequate access controls must be designed into every system to ensure that only authorized users are allowed to access the system and that they are not permitted to exceed their level of authorization.
2) Second, the system must maintain the confidentiality of vital data through the use of appropriate encryption and data protection technologies.
3) Next, the system should provide both an audit trail to enforce individual accountability and a detective mechanism for illegitimate activity.
4) Finally, depending on the criticality of the system, availability and fault-tolerance issues should be addressed as corrective actions.
1.2.4 Design Review
After the design team completes the formal design documents, a review meeting with the stakeholders should be held to ensure that everyone is in agreement that the process is still on track for the successful development of a system with the desired functionality. This design review meeting should include security professionals who can validate that the proposed design meets the control specifications developed in the previous phase.
1.2.5 Coding
Developers should use the secure software coding principles discussed in this chapter to craft code that is consistent with the agreed-upon design and meets user requirements.
1.2.6 Code Review Walk-Through
Обзор кода: пошаговое руководство
Project managers should schedule several code review walk-through проход meetings at various milestones этапах throughout the coding process.
1.2.7 Testing
The initial system testing using development personnel to seek out any obvious errors.
Regression testing formalizes the process of verifying that the new code performs in the same manner as the old code, other than any changes expected as part of the new release.
User acceptance testing (UAT), where users verify that the code meets their requirements and formally accept it as ready to move into production use.
Once this phase is complete, the code may move to deployment.