CompTIA CySA+ Cybersecurity Analyst Certification: Software and Systems Security - Software Assurance Best Practices

Objective 2.2  Explain software assurance best practices
Computing devices have two major components: software and hardware. We will discuss hardware assurance later in the next module, but software assurance is extraordinarily important. This is where most users, and indeed security professionals, have their issues with security. The environment within which software, hardware, data, and the user interact with each other is complex.

In this module, we will discuss several aspects of software assurance, from many different angles. First, we’ll discuss software platforms, such as mobile, web, and client/server, among others. We’ll also discuss the software development lifecycle, and a relatively new paradigm, DevSecOps.

You’ll also learn about software assessment methods as well as analysis tools. We will talk about service-oriented architecture, as well as software security best practices such as secure coding. All these ingredients are critical for assurance that software performs as expected, is functional, and secure.

Platforms
The platform that software runs on is a function of different things, including hardware (for example, processor type and architecture), operating system (for example, Windows versus macOS or Linux), and implementation paradigm (web-based versus client/server versus mobile device). The platform describes the entire environment that the software runs on; in this module, we will discuss the various popular platforms, including mobile devices, web-based applications, and traditional client/server architecture. We will also discuss specialized platforms such as embedded systems, system-on-chip, and firmware implementations. While there are many software assurance practices and processes that are common across all platforms, each different platform implementation also has unique characteristics that we will discuss.

Exam tip: Remember that the platform an application runs on consists of its hardware, operating system, and entire operating environment.

Mobile
Mobile platforms are ubiquitous throughout the world. With the advent of smartphones, tablets, laptops, and other personal mobile devices, software design and deployment methods changed. There are many different manufacturers of mobile devices as well as different operating systems and mobile applications, or apps, that present different issues. You may find a certain mobile app, for example, that you can download and run on any type of mobile operating system, but under the surface, the app is different for different hardware types and mobile OSs.

Some mobile apps are designed for individual use, and you can download them from the respective app store for the mobile device platform you are using, such as iOS or Android. Some apps are developed for business use and may be deployed even from an organization’s own app store.

The development model for each of these types of apps is different. For example, Apple severely restricts its developers and applications with stringent requirements, including security. Android, on the other hand, allows developers to have a freer hand in developing apps that are deployed in the Google Play Store and other online app stores.
Another issue with mobile apps is the services and data they are allowed access to on a mobile device. Some apps tend to embrace an all-or-nothing paradigm in that you must allow all the data and services that it wishes to access, or simply not use the app, whereas other types of apps may allow you to be more granular and pick and choose the services and data on your mobile device that they are allowed to access. This goes back to one of the most fundamental principles of security: the principle of least privilege. An application should only be allowed to access the data and services it needs to perform its functions, and no more. Some applications seem to require more access than they truly need, and this can probably be traced back to collecting user data for the application developer to use for marketing purposes, or maybe even for some nefarious reason. For example, does the latest photo-editing app that you want to download really need the ability to make phone calls, as well as access your contacts, location, and other sensitive data?

Web Application
Web applications represent a significant portion of the applications that are developed today, due to the wide availability of high-speed Internet, tiered architectures, and the rich content available for these applications. Web applications can be created for almost anything—from personal banking applications to cloud-based office productivity suites, social media, and much more. These applications represent the future for many users, and they are popular due to their modularity and portability across different platforms.
 

The simplest of web applications can be deployed using a web server, with either static or dynamic content, serving as the front-end user interface, with a back-end application engine on the same server. When you add more layers of complexity, such as an application server on a different host, load-balancing capability through clustering, authentication mechanisms, and possibly a separate database server connected into the application, you have the most common architecture of all—the n-tier architecture, where n can represent any number of layers of components.
Web applications are built with many different components, with HTML as one of the fundamental building blocks, but also consisting of other programming languages, such as Java, Microsoft’s .NET framework, XML, and many other components. When you also include an enterprise database application, as well as the supporting infrastructure, this causes the application to become overly complex. Not only does it expand the attack surface for a malicious entity, but it also expands the application and user space you must secure.

Client/Server
The client/server architecture is the traditional one that we have seen in computing for many years. There are two pieces to this architecture. In this architecture, a client (for our purposes here, a piece of software that presents a user interface and interacts on the user’s host machine) accesses a server, which can be a physical machine running server-based software, and exchanges data with that software. An example of this paradigm would be an application residing on the user’s host machine, which accesses a database on a remote server.
This is a simplistic architecture, and the primary concerns here are the security of the client application and how it interfaces with the operating system on the host machine as well as how it interfaces with the server software. Considerations here include the protocols that it uses to exchange data, as well as authentication mechanisms that it uses to authenticate the user to the server-side software. Note that both the client application and the server component it communicates with can also exist on a single machine; although typically not seen this way, the client/server paradigm is not only limited to separate hosts.

Embedded Platforms
Embedded systems are typically not standalone computing devices; they are part of a larger device, and they serve to control those devices, which traditionally may not be connected or simply physically isolated. This could include consumer devices such as refrigerators and televisions, but it also includes electronic systems that help to control aircraft, factories, utility grids, and so on. Embedded devices are usually found with real-time operating systems, which are implemented for speed, efficiency, and limited functionality. Embedded platforms usually have software implemented as specific code that is very utilitarian in nature. The code that goes with embedded systems is usually not easily upgradable, except through specialized hardware and software, since it is imprinted on the chip and is not erased when power is removed from the device.

KEY TERM: Embedded platforms are typically specialized devices (as opposed to general computing devices) that have their operating systems implemented as firmware on a chip. They perform highly specialized functions and can be seen in industrial control systems, consumer electronics products, and other Internet of Things (IoT) devices.

Firmware
Firmware is the software embedded on a chip or other hardware device. It is static in nature and can be difficult to update or change its configuration. Firmware is software used for a specific purpose; it is not general-use software. It is used to store and load initial configuration information for hardware on a computing device, for example.

System-on-Chip (SoC)
As described in Objective 1.5, a system-on-chip (SoC) is an embedded system in which software and hardware are integrated into a single computer chip. The chip is self-contained and consists of a processor, system RAM, and other critical components miniaturized into a single integrated circuit. A system-on-chip implemented into a piece of hardware is extremely fast, self-contained, and reliant; it uses much less power and is more efficient. A software consideration for a system-on-chip, implemented as firmware, is that it is embedded; the software configuration is static in nature, making it difficult to update and patch without specialized equipment. This means that if there are any discovered vulnerabilities in the firmware, they are difficult to mitigate.

Service-Oriented Architecture
Examining software from a platform perspective is especially useful since it looks at the entire operating environment the software must work in. Another way, however, of looking at software is by the functionality or service it provides. This is called service-oriented architecture (SOA), which describes software components that interface and interact with each other to provide services via standardized components. These components include an application programming interface, or API, which allows developers to create code to interact with various components and pass data and services between each other. SOA makes heavy use of markup languages, such as XML, for communications between components.
 

There are several basic requirements of a service-oriented architecture:
- Self-contained components
- Platform neutrality
- Modularity
- Component reusability
- Standardized APIs and other protocols to service requests from and provide responses to other components
- Business function-oriented services

In this section, we’re going to discuss various components that a SOA can use to provide services between and make use of. A few of these are, but certainly not limited to, the Security Assertions Markup Language, the Simple Object Access Protocol, Representational State Transfer, and microservices. We will briefly describe each of these in the upcoming sections.

Exam tip: Service-oriented architecture is concerned about the services that the components of an application can provide to other components of other applications, as well as how they communicate and interact with each other.

Security Assertions Markup Language (SAML)
Security Assertions Markup Language (SAML) is a markup language much like HTML and XML. Markup languages, as you will recall, essentially format, or mark up, different elements of a text-based file. They simply tag these elements for use by an application. SAML has specific tags in its structure that allow applications to use formatted information about the user, including their identity and other authentication and authorization information. The current standard is SAML 2.0.

There are generally three components to SAML:
- The user (called the “principal”)
- The identity provider (the entity authenticating the user’s identity)
- The service provider (the entity who controls the service or application the user is authenticating to)

SAML is a common standard used across identity and service providers. When a user requests a service or access to a website, for example, the service provider requests identification information from the user, who submits it through an application such as a web browser. The service provider then takes that information and requests authentication from the identity provider. The identity provider replies to the service provider with authentication information as well as a token containing assertions, which are essentially authentication and authorization information for the user. Based on this information, the service provider can then allow or deny access to the service, application, or resource.

Simple Object Access Protocol (SOAP)
Simple Object Access Protocol (SOAP) is used in the enterprise service bus, which is where all communications and interactions take place between different services and applications. SOAP is a messaging protocol used to facilitate these communications and allows clients to access services over HTTP, regardless of the application server platform.

SOAP has three major components:
- Message envelope (determines which messages are allowed and how the recipient processes them)
- Encoding rules used to define data types
- Standards on which remote procedures and services can be accessed

SOAP uses XML as the basis of its communications since this is an open, common standard. However, SOAP sometimes has difficulty with complex communications, which can be a detriment to its performance and functionality.

Representational State Transfer (REST)
Representational State Transfer (REST) is an architectural method used to overcome some of the limitations with the older Simple Object Access Protocol. It is designed to allow stateless communications between services, applications, and web-based resources.

REST has the following characteristics:
- Uses standardized URLs to identify resources.
- Uses a client/server architecture.
- All transactions are stateless, meaning that each request and response contains enough information to be complete and understood by both systems, regardless of previous transactions.
- Responses dictate whether they are cacheable or not by a web proxy.
- Has a uniform, modular interface.

Microservices
Microservices are also a popular service-oriented architectural method, like REST. Microservices are individualized deployable application services that are focused on business transactions. They are very decentralized and do not have a lot of dependencies on other services; they are designed to perform very individualized tasks independently of other services. Because of their size and independence, they are easily developed. However, security can be an issue in that they all interact with each other and other services independently, with little security overhead. This is where log collection aggregation is useful, in that you can determine the activities and interactions between microservices when aggregating and analyzing log data.

Software Development Lifecycle (SDLC) Integration
The Software Development Lifecycle (SDLC) is a process that describes how software is planned, designed, created, tested, implemented, and maintained throughout its useable life. It is a formalized framework consisting of steps, tasks, and processes that drive all activities associated with software development and use.

There are several models used for SDLCs, including the older Waterfall development model, spiral or iterative models, as well as newer models such as Rapid Application Development (RAD), Agile, and other prototyping or rapid deployment models.

All of these models impose, to various degrees of structure and rigidity, a formal process for setting software functionality, performance, and security requirements; designing the software; building or acquiring it; testing and integration; as well as implementing it in the organization and maintaining it. For the most part, performance and functionality requirements have been traditionally the focus of development models, with little emphasis on security requirements. This is changing, however, and security is increasingly a part of software development, with the advent of secure coding practices (discussed later in the module), as well as newer development models, such as DevSecOps, discussed next.

Exam tip: You are not required to know the various SDLC models for the exam, but they are useful to understand.

DevSecOps
In a traditional development model, programmers did not always interact effectively with the people who would be the end users of the software they were producing. This often led to issues including unmet functional requirements, performance issues, and general unsuitability of the software for its intended purpose. As time passed, these issues were addressed by a more integrated community of developers and users. This paradigm became known as DevOps since it combined the development and operations worlds. However, security was still left out for the most part, causing a longer-term problem of few or ineffective security measures integrated into the software. The end result was that, quite often, security was considered after the fact. In other words, it was “bolted on” rather than being “baked in,” or integrated into, the software.
This was the case until fairly recently, when a new paradigm, consisting of development personnel, operators and users, and security personnel, was invented. This, of course, is called DevSecOps and allows those three segments of stakeholders to integrate requirements while the software is being developed. The result of this new way of doing business is that software is developed with continual input from both users and security personnel, as well as quality assurance folks, thus significantly reducing errors and security issues as well as functionality and performance problems. This saves significant time that would have previously been spent on rework or fixing software bugs. This allows a more rapid development cycle while still maintaining quality software, which in turn allows faster integration and implementation.

Secure Coding Best Practices
As previously mentioned, software developers have not always integrated security considerations into their development processes or code. Security functions were often left out in favor of creating software that was useful, functional, and performed well. Functionality has always been the antithesis of security; generally, the more functional a piece of software or system is, the less secure it is since security tends to restrict functionality. People who are not security-minded generally accept this, because the thought is that functionality also equals convenience, speed, and efficiency. The problem with this thought process is that software can be extremely functional and fast right up until the point when a security issue occurs, and it creates a denial-of-service condition or allows data to be accessed by an unauthorized person. Then, the organization tends to pay for that speed and efficiency with data loss and, potentially, liability. Functionality and security must be in a delicate balance, and once this was realized by the development community, there was a concerted effort to create secure software. In order to accomplish this goal, development practices had to be changed, with a focus geared more toward the security side while maintaining functionality.
From this great realization came secure coding best practices. These practices form a framework that drives how programmers must develop software to be as functional as required, yet maintain integrated security functions that prevent data leakage, ensure data integrity, and be robust enough to be available when the user needs it. In the next few sections, we are going to discuss a few of these key practices, although there are many more. These key practices include input validation, output encoding, session management, authentication, data protection, and parameterized queries.

Input Validation
Input validation is one of the most important secure coding practices that programmers should implement to cover a wide variety of potential security issues. Many different security vulnerabilities, particularly injection attacks, could be solved if input validation were performed within the application itself. This includes validating textual and numerical data as well as preventing program escaping by unauthorized input.
Input validation can occur on the client side, such as through the client application or even web browser, or on the server side, where the application code resides. Client-side validation is often implemented using scripts and can be more efficient because it eliminates potential input problems early in the process. However, client-side validation can be easily circumvented using a variety of tools. Server-side validation may be less efficient, but it ensures that the validation process is sound.

Output Encoding
Attackers can use a wide variety of techniques to inject malicious code into an application. One of them is to use scripts (for example, with the <script> HTML tag) as part of their input.

Input validation, if it is properly implemented, should intercept this before the application has a chance to execute it, but this does not always happen. Another technique to prevent this type of attack is called output encoding, which converts any user input, including potentially malicious embedded scripts, to inert data that a web browser cannot interpret as HTML. This technique is widely used to help in preventing cross-site scripting attacks.

Session Management
A typical web browsing session consists of, in its basic form, a series of requests and responses between the client browsers and web servers. Sometimes these transactions depend on each other or a previous transaction to process completely. However, HTTP is a stateless protocol; in other words, it does not track the state of requests and responses in relation to each other. Each request and response is completely independent of the transaction that happened before it and retains no “memory” of the previous request or response. To get around this, every time there is a session between the client browser and a web server, a small text file is generated and stored on the client to retain information necessary for future requests and responses. These text files are called cookies.

An issue with cookies is that they may sometimes contain sensitive information, such as authentication information.

Cookies are sometimes created, stored, and sent back and forth in plaintext, which enables an attacker to intercept the information stored in the cookie.
Securing a session is the process of ensuring that sensitive information sent back and forth during a web session cannot be easily sniffed or intercepted by a malicious entity. Using the HTTPS protocol is one way to do this. HTTPS, remember, encrypts the session using Transport Layer Security (TLS). Additionally, secure coding techniques can go far in securing the session between the user and a web server.

These techniques include the following:
- Use encryption, such as HTTPS, whenever possible.
- Use strong authentication methods.
- Encrypt and expire cookies after each session.
- Disallow third-party cookies.
- Use session IDs that are difficult to predict (using complex pseudorandom numbers whenever possible).

Authentication
This is yet one other area where programmers need to be mindful of how they write code to accept authentication into an application. Many applications rely on external secure authentication methods, such as pass-through authentication from Active Directory. However, some applications use their own authentication mechanisms, which are not always secure or robust. Programmers can cause authentication issues for their applications by using simple username and password combinations, for example, that don’t require complex passwords or encryption. They could also hardcode passwords into application code, which is a bad idea since an attacker could gain access to that code and determine any embedded passwords.
Programmers who need to create their own authentication mechanisms in applications should attempt to use multifactor authentication whenever possible and avoid username/password combinations. However, if username/password combinations are required, they should enforce standard password rules, such as complexity, minimum length, and password expiration. Passwords should never be stored or transmitted in cleartext; there should be encryption modules built in to the application to handle encrypting credentials whenever possible. Additionally, mechanisms that prevent brute force attack, such as account lockout, should be implemented. And, finally, all access to the application, especially privileged access, should be logged and audited.

Data Protection
Software applications, in addition to protecting authentication information, must protect all sensitive data that is processed or generated by the application, as well as data that is stored, transmitted, or received through the application. Data typically exists in three states: at rest, meaning while it is stored on media; in transit, meaning it has been transmitted over a networking medium; and in process. In process means that it is currently residing in memory and being used by the CPU.
Data at rest can be protected using various methods. In conjunction with the operating system and its security mechanisms, such as rights, permissions, and so on, an application can also protect data in storage by allowing access to it from only authorized users. Both the operating system and application can also encrypt or otherwise obfuscate data while it is stored. Some applications may store data in a format other than simple files; large relational databases are an example of this. Database records are stored in multiple database files, of course, but not as a single file entity that can be accessed by means other than through the database application itself.
Data in transit can also be protected by both the operating system and application. Even if the operating system or network does not encrypt the application’s data, the application can be responsible for encrypting any data that is sent between it and the receiving application on the remote host. Applications can also be configured to send and receive data only to and from particular hosts or domains, as well as use stronger authentication mechanisms. Applications can also have built-in integrity mechanisms to ensure that data has not been altered during transit between applications on remote hosts.
In terms of secure application programming, developers can do their part to ensure data protection by using secure techniques to ensure memory protection so that both the application and data can execute in secure memory areas that are not easily overwritten or corrupted by buffer overflow attacks, for example. Programmers must ensure that only secure functions are used during program execution so that data being processed will not be compromised or altered in any way.

Parameterized Queries
Another form of input validation, specifically designed to thwart SQL injection attacks, is parameterized queries. This type of input validation treats all user input as parameters to a function rather than a literal query, so anyone attempting to input an SQL statement into an input dialog box on a web form, for example, will be disappointed. Programmers can specify exactly what type of parameters they wish for their functions, such as date, number, or even a username and password combination. This way, the attacker cannot put SQL statements into the input field of a web form, for instance, and generate a structured SQL statement.

Note: All these secure coding best practices should be used in conjunction with each other, especially input validation, output encoding, and parameterized queries, since this is a multilayered approach to preventing some of the more common attacks.

Software Assessment Methods
Secure coding is just one part of software assurance. After the code has been developed in as secure a manner as possible, we must examine it to make sure that it fulfills its functional and performance requirements, but also is secure. There are several things we look for in software security—data leakage, strong authentication, and so forth. These things are determined by assessing the software through various types of tests and reviews. In the next few sections, we’re going to discuss some of these assessment methods. We will look at user acceptance testing, stress testing, security regression testing, code review, and look at some of the analysis tools we can use to assess software security. We’ll also quickly discuss the formal methods that organizations can use to verify that software meets its critical functional, performance, and security requirements.

User Acceptance Testing
While there are many kinds of application tests, including unit testing, regression testing, and so on, user acceptance testing is critical in that this is where the user tests the application and checks for performance and functionality. The user has the responsibility to make sure that the software works as advertised and meets the requirements originally levied on the programmers.
User acceptance testing also presents the opportunity to closely look at the different interactions a user may have with software, to make sure it performs as expected and to uncover any issues that may have been missed by programmers. For example, one security consideration in user testing is how the user interacts with the login and authentication facility. If the user can cause errors during the process or if the login process is not built correctly, it could actually present a security issue if it allows an attacker to take advantage of a programming mistake.

Stress Testing
Stress testing is a type of test designed to put an application under a load from a large amount of network traffic, processes, or data. It is designed to work an application hard to uncover any performance or security issues that may result from an application not being able to handle its designed workload. There are several manual and automated methods for performing stress testing, including sending large amounts of network traffic or data to an application, throttling its bandwidth during heavy processing times, connecting large numbers of users at one time, and so on. The goal is to push an application to its limits to see how it reacts and to make sure it can handle its projected workload.
Many applications react badly to heavy processing loads, which may cause them to crash, perform very slowly, or even throw errors. In turn, this could allow an attacker to gain insight as to how the application is built. In a worst-case scenario, an excessive performance load could cause an application to default to a nonsecure state or allow an attacker to take advantage of it and run arbitrary code. Stress testing is a vitally important part of security testing.

Exam tip: Application stress testing involves sending high volumes of data, including network traffic, into an application to see how it reacts to an excessive workload. The goal here is to cause the application to max out its RAM, processor, and other resource usages, so you can observe how it reacts to those conditions. Some applications will crash or cause a security issue if they are overtaxed.

Security Regression Testing
Regression testing involves introducing a new system or application into an environment where there are already existing systems and applications. The goal is to see how the new application interacts with the other ones; this can uncover any interoperability issues, but also security issues as well. For example, if older applications are designed with legacy security controls, such as older encryption algorithms, the newer application may not communicate with them at all or may default to a less secure state to maintain interoperability. Security regression testing tells you if your security methods and mechanisms built into a new application are compatible with your older ones. This is where design tradeoffs may have to occur in that you may have to force your new application to default to less secure communications and authentications methods if you must maintain compatibility with legacy applications. This also may cause you to determine that you must replace those older applications or at least upgrade their security mechanisms.

Code Review
Code review is an assessment process that involves an in-depth check on software application code, to make sure it has been written properly, is well structured, meets its functional and performance requirements, and is, of course, secure. Different review methods are available as part of a secure development methodology, including both manual and automated review processes.

A manual review involves an individual, typically another programmer familiar with the programming language and software requirements, going line by line over the code to look for structural issues, common mistakes, and so on. Automated code review involves the use of software applications that can take code apart and look for predetermined issues, particularly security vulnerabilities.

An automated review is typically very quick and efficient for looking for a set of known programming mistakes or security issues and confirming that structure, syntax, and so on, are sound. However, a manual review can look for items not included in an automated code review application’s vulnerability library. An experienced programmer will often use their intuition and knowledge of programming, as well as security, to look for issues that an automated program may not find.
Code reviews typically take place iteratively during various stages of the Software Development Lifecycle. Along with code review, several tools can be used for code analysis, including static analysis and dynamic analysis, discussed next.

Static Analysis Tools
When using automated tools, there are primarily two different types of analysis we can perform on application code to test its security. Static analysis tools are those that use predetermined libraries of issues to check for in code. These tools examine code line by line, looking at different objects, checking their properties, references, and so on. Static analysis tools can check for a wide variety of issues automatically, such as input validation weaknesses, code injection, and so on. Again, these are predetermined and already programmed into the static analysis tool. Checking for these common vulnerabilities can save considerable time and effort on the part of programmers since the entire process of checking for common vulnerabilities can be pretty much automated and checked quickly and efficiently.

There are many different static analysis code tools in the marketplace, but a few popular examples are Fortify, Coverity, and SonarQube.

Dynamic Analysis Tools
Even with manual code review, which uses programmer knowledge, insight, and experience, as well as static code analysis, there’s no way to accurately predict how software will behave until it is actually executing. Dynamic code analysis uses automated tools to examine code during execution. Dynamic analysis tools employ many different options, allowing you to stop code execution automatically upon discovery of certain error or security conditions, as well as halt execution at predefined checkpoints. Some dynamic analysis tools allow a wide variety of input to be used during code execution so that the tool can follow different execution paths based on different test conditions. The more complex the code, the more difficult and time-consuming it is for a dynamic analysis tool to adequately cover the range of all possibilities of execution; code coverage is the measure of how much of a program can be examined by the tool. Dynamic tools only can only give results about code that has been examined during execution; if there are parts of the software that have not been executed, the dynamic analysis tool can provide no information.

Formal Methods for Verification of Critical Software
In addition to the methods we have discussed already, there are also some highly structured testing methods used for critical software (software that could control medical infusion pumps, aircraft in flight, or missile defense systems, for example). These software applications must be immediately responsive, resilient, and secure. Formal methods use statistical and other mathematical models to clearly define every single parameter of a piece of software and predict its behavior under a variety of circumstances.

These formal methods are used throughout the entire Software Development Lifecycle—from requirements, design and architecture, development, testing, and even beyond, through the implementation and maintenance phases of the software’s life.

Formal methods can be very time-consuming, tedious, and expensive to perform. Typically, only large organizations developing and running some of the aforementioned types of critical software may use them because of this. This is in addition to all the other methods we have discussed thus far.

Exam tip: Understand the differences between manual code review, static analysis, and dynamic analysis. Manual code review is performed by an experienced programmer.

Static analysis is an automated method that looks for predetermined vulnerabilities, such as SQL injection. Dynamic analysis is an automated method that requires the code to be running so it can observe any unpredictable behaviors.

REVIEW
Objective 2.2: Explain software assurance best practices In this module, we discussed various methods and processes for ensuring that software is developed in as secure a manner as possible, as well as assurance that it secures the data it uses. First, we talked about different platforms that software can run on, including on mobile devices, web applications, client/server architecture, and embedded devices, as well as their software assurance challenges.
We also discussed service-oriented architecture, which looks at software in terms of the services it provides to other applications. We talked about three service-oriented architecture methods in particular: SAML, which is used to exchange secure authentication information about a user to different applications; SOAP, an XML-based protocol used to exchange messages between applications; and REST, an architecture method used to exchange data between applications, considering the stateless nature of the Web. Microservices are individual, deployable services that are focused on performing specialized transactions.
We also discussed the overall Software Development Lifecycle (SDLC), which is a formal methodology of managing software from its inception all the way to its retirement. Various SDLC models include Waterfall, Agile, and RAD. DevSecOps is the synthesis of the development, operations, and security communities, working together to ensure that software performs as required, meets its functional requirements, and is secure.
To ensure that software is both functional and secure, we discussed secure coding best practices, which can be used to help prevent many of the common security issues seen in modern applications (injection attacks, for instance). We discussed the importance of input validation, which can prevent many of these attacks simply by ensuring that any user input is checked and rendered ineffective as executable code. We also discussed output encoding, which effectively does the same thing to any user input so that it cannot be executed by the application. Session management is the process of securing sessions between the client and a server, through encryption as well as strong authentication methods. Authentication methods should be left to the underlying operating system or, absent that practice, implemented as secure authentication mechanisms in applications that do not store or pass credentials in cleartext, that enforce password complexity requirements, and that use strong authentication methods whenever possible. Applications should also protect any data that they use, either in storage, in transit, or residing in memory. Various methods include encryption, of course, as well as rights and permissions and strong authentication. Developers can use multiple secure coding techniques to protect data, including bounds checking and memory protection. Parameterized queries are a method of preventing injection attacks, particularly SQL injection, by rendering any user input as a parameter of a function rather than as executable code.
To have faith in our software as secure, we must test it. Software assessment methods include user acceptance testing, application stress testing, and security regression testing. All three of these methods are designed to ensure that users can interact securely with applications, that the applications can handle the maximum required workload without failing a nonsecure state, and that the applications interact with other components in a secure manner. Code review is a method of examining the application software code to ensure that it is functional, secure, and does not have any inherent vulnerabilities in it. Manual code review requires an experienced programmer who understands both programming and security. This is typically a line-by-line code review. We can also use automated tools to analyze code. Static analysis refers to looking at code for predefined vulnerabilities, such as injection attacks and buffer overflows. Dynamic analysis refers to looking for issues while the code is actually executing, to see if it behaves in an unpredictable manner. In addition to static and dynamic methods, there are also formal methods used primarily on critical software, where security failures could have dire consequences. These methods are expensive, tedious, and primarily involve deep mathematical analysis throughout the entire SDLC.