Security in the SDLC

{`
Kelly School of Business
Indiana University
Information Systems Graduate Programs
`}

SDLC - A Conceptual Overview

• SDLC basic phases
• Initiation
• Development / Acquisition
• Implementation / Assessment
• Operation / Maintenance
• Disposal
• Security must be included in all phases of development

Security Considerations during Initiation

• Security is looked at more in terms of business risks with input from the information security office
• Key activities
• Initial delineation of business requirements in terms of confidentiality, integrity, and availability
• Determination of information categorization and identification of known special handling requirements to transmit, store, or create information (such as PII etc.)
• Determination of any privacy requirements

Development/Acquisition

• Key activities
• Conduct the risk assessment and use the results to supplement the baseline security controls
• Analyze security requirements
• Perform functional and security testing
• Prepare initial documents for system certification and accreditation
• Design security architecture
• Security analysis of complex systems will need to be iterated until consistency and completeness are achieved

Implementation/Assessment

• The system will be installed and evaluated in the organization’s operational environment
• Key activities
• Integrate the information system into its environment
• Plan and conduct system certification activities in synchronization with testing of security controls
• Complete system accreditation activities

Operations/Maintenance

• The system is monitored for continued performance in accordance with security requirements and needed system modifications are incorporated
• Key activities
• Conduct an operational readiness review
• Manage the configuration of the system
• Institute processes and procedures for assured operations and continuous monitoring of the information system’s security controls
• Perform reauthorization as required

Security Considerations during Disposal

• Information security issues associated with information and system disposal should be addressed
• Key activities
• Build and Execute a

Disposal/Transition Plan

• Archive of critical information
• Sanitization of media
• Disposal of hardware and software

Application Security

Current Software Environment

• Layered Model
• OS
• Application software
• Open Source Software (OSS)
• Proprietary software
• Freeware
• Shareware
• Custom software
• API libraries
• Engine services – database & web servers
• Remote procedure calls

Operating Systems Vulnerabilities

Source: http://www.gfi.com/blog/most-vulnerable-operating-systems-and-applications-in-2014/

Application Vulnerabilities

Source: http://www.gfi.com/blog/most-vulnerable-operating-systems-and-applications-in-2014/

Security Issues in Source Code (1/2)

• Buffer Overflow
• End user programming
• Covert channels
• Storage
• Timing
• Malware
• Malformed input attacks
• Cross-site scripting attack
• SQL injection

Security Issues in Source Code (2/2)

• Memory/object reuse
• Executable content/mobile code
• Social Engineering
• Time of Check / Time of Use
• Between-the-lines attack
• Trapdoor/backdoor

Malware

• Software or programs that are intentionally designed to include functions for penetrating a system, breaking security policies, or carrying malicious or damaging payloads
• Programming bugs or errors are generally not included in the definition of malware
• Mostly used to attack and destroy system integrity
• Malware is a collective class of malicious software including viruses, logic bombs, pranks, RATs, Trojans, worms, zombies, etc.
• Blended attacks

Malware Types (1/2)

• Virus
• “A program that modifies other programs to contain a possibly altered version of itself”
• A virus is defined by its ability to reproduce and spread but to do so with the aid of the user in some form
• Types - file infectors, boot sector infectors, system infectors, email virus, macro virus, multipartite, etc.
• Worms
• A worm may be thought of as a virus with the capacity to propagate independent of user action
• The lack of requirement for user involvement means that worms have a significant speed advantage when spreading

Malware Types (2/2)

• Trojans
• A Trojan is a program that pretends to do one thing while performing another unwanted action
• DDoS Zombies
• Computers in between the attacker and the target that are used to generate DoS attack
• Logic bombs
• Software modules set up to run in a dormant state and to monitor a specific condition or set of conditions and to activate their payload under those conditions
• Spyware
• Software that covertly gathers user information through the user's Internet connection without his or her knowledge, usually for advertising purposes

Malware Protection

• Scanners
• Activity Monitors
• Change Detection
• Anti-Malware Policies
• Malware Assurance
• Zero-day/Zero-hour Web Reputation
• Google vs Microsoft

• Trusted Computing Base (TCB)
• The TCB is the collection of all of the hardware, software, and firmware within a computer system that contains all elements of the system responsible for supporting the security policy and the isolation of objects
• The security kernel is made up of all of the components of the TCB, and is responsible for implementing and enforcing the reference monitor for enforcing a security policy
• Requirements
• Completeness
• Isolation
• Verifiability
• Processor privilege states
• The processor privilege states protect the processor and the activities that it performs
• Many operating systems use two processor access modes: user mode and kernel mode.

User application code runs in user mode, and operating system code runs in kernel mode

• Security controls for buffer overflows
• Buffer overflows must be corrected by the programmer
• Detection involves reverse engineering programs and looking at operations of the application
• Hardware controls are also possible
• Data Execution Prevention (DEP)
• Parameter checks and enforcement
• Process isolation and Memory protection
• Covert channel controls
• Cryptography
• Password protection techniques
• Granularity of controls
• Mobile code controls
• Running code in a sandbox
• Digital signatures
• Software Forensics
• Configuration Management

Secure Coding Practices

• Define security requirements
• Identify and document security requirements early in the development life cycle and make sure that subsequent development artifacts are evaluated for compliance with those requirements
• When security requirements are not defined, the security of the resulting system cannot be effectively evaluated

Secure Coding Practices

• Model threats
• Use threat modeling to anticipate the threats to which the software will be subjected
• Threat modeling involves identifying key assets, decomposing the application, identifying and categorizing the threats to each asset or component, rating the threats based on a risk ranking, and then developing threat mitigation strategies that are implemented in designs, code, and test cases

Secure Coding Practices

• Validate input
• Validate input from all untrusted data sources
• Proper input validation can eliminate the vast majority of software vulnerabilities. Be suspicious of most external data sources, including command line arguments, network interfaces, environmental variables, and user controlled files

• Heed compiler warnings
• Compile code using the highest warning level available for your compiler and eliminate warnings by modifying the code
• Architect and design for security policies
• Create a software architecture and design your software to implement and enforce security policies
• For example, if your system requires different privileges at different times, consider dividing the system into distinct intercommunicating subsystems, each with an appropriate privilege set
• Keep it simple
• Keep the design as simple and small as possible
• Complex designs increase the likelihood that errors will be made in their implementation, configuration, and use
• Additionally, the effort required to achieve an appropriate level of assurance increases dramatically as security mechanisms become more complex

https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices

• Default deny
• Base access decisions on permission rather than exclusion
• This means that, by default, access is denied and the protection scheme identifies conditions under which access is permitted

https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices

• Adhere to the principle of least privilege
• Every process should execute with the least set of privileges necessary to complete the job
• Any elevated permission should be held for a minimum time. This approach reduces the opportunities an attacker has to execute arbitrary code with elevated privileges

https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices

• Sanitize data sent to other systems
• Sanitize all data passed to complex subsystems such as command shells, relational databases, and commercial off-the-shelf (COTS) components
• Attackers may be able to invoke unused functionality in these components through the use of SQL, command, or other injection attacks

https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices

• Practice defense in depth
• Manage risk with multiple defensive strategies, so that if one layer of defense turns out to be inadequate, another layer of defense can prevent a security flaw from becoming an exploitable vulnerability and/or limit the consequences of a successful exploit
• For example, combining secure programming techniques with secure runtime environments should reduce the likelihood that vulnerabilities remaining in the code at deployment time can be exploited in the operational environment

https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices

• Use effective quality assurance techniques
• Good quality assurance techniques can be effective in identifying and eliminating vulnerabilities
• All test data should be sanitized
• Penetration testing, fuzz testing, and source code audits should all be incorporated as part of an effective quality assurance program. Independent security reviews can lead to more secure systems
• External reviewers bring an independent perspective; for example, in identifying and correcting invalid assumptions

https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices

• Adopt a secure coding standard Develop and/or apply a secure coding standard for your target development language and platform
• g. CERT Secure Coding Standards

Environments for the Development Life Cycle

• Application development, deployment, and hosting in a large IT organization often involve separate development teams working in parallel on numerous applications for deployment to a shared hosting environment.
• The ways in which an application is exercised at the various stages of its life cycle and deployment schedule require several different parallel instantiations of the application.
• Application Deployment Environments
• Development, integration, testing, staging, production

Application Deployment Environments

Development Environment

• The development environment is where unit level development is done.
• The development environment is a “sandbox” environment where developers are free to use various application infrastructure elements without the constraints, for instance, of the security that will exist in other environments.

Integration Environment

• The integration environment is where application units (software modules, data schemas, and data content) are first assembled and then tested as an integrated suite.
• This environment is also volatile but is much less so than the development environment.
• The objective here is to force coherence among the independently developed modules or schemas.
• This is typically an environment where developers do not have all the permissions that they had in the development environment.

Test Environment

• The test environment is where a “release candidate” grade version of the application is run through testing exercises.
• It is as tightly controlled as the production environment and also substantially less volatile than integration.
• The objective here is to assume relative stability of the integrated application and test its stability, correctness, and performance.
• This environment is usually off limits to developers.

Staging and Production Environments

• The staging environment is where an application resides after it has been fully tested in the test environment.
• It provides a convenient location from which to deploy to the final production environment.
• Because the staging environment is often used to perform final tests and checks on application functionality, it should resemble the production environment as closely as possible.
• The production environment is where the application is actually used by the organization; it is the least volatile and most tightly controlled.

Security of the Data and Web Environments

Databases and Data Warehouses

• Security requirements for databases
• Transaction persistence
• The state of the database is the same after a transaction (process) has occurred as it was prior to the transaction
• Fault tolerance
• Rollback recovery
• Shadow recovery
• Sharing by multiple users without affecting integrity of data Security controls

Federated Databases

• A federated system is a special type of distributed database management system
• A federated system consists of a database server instance that operates as a federated server, a database that acts as the federated database, one or more data sources, and clients (users and applications) that access the database and various data sources.
• With a federated system, you can send distributed requests to multiple data sources within a single SQL statement.
• Authentication and Authorization is key in securing federated databases
• Use a reference monitor between subject and the federated database

Database Vulnerabilities and Threats

• Aggregation
• Bypass attacks
• Compromising database views used for access control
• Concurrency
• Data contamination
• Deadlocking
• DoS

Database Vulnerabilities and Threats…

• Improper modification of information
• Inference
• Interception of data
• Query attacks
• Server access
• Time of check/Time of use
• Web Security
• Unauthorized Access

DBMS Controls

• Lock controls
• Enable only one user to perform an action on the data at a time and prevent deadlocks
• The ACID Test
• Atomicity
• states that database modifications must follow an “all or nothing” rule. Each transaction is said to be “atomic.” If one part of the transaction fails, the entire transaction fails.
• Consistency
• states that only valid data will be written to the database. If, for some reason, a transaction is executed that violates the database’s consistency rules, the entire transaction will be rolled back and the database will be restored to a state consistent with those rules.
• Isolation
• requires that multiple transactions occurring at the same time not impact each other’s execution
• Durability
• ensures that any transaction committed to the database will not be lost

DBMS Controls

• Access controls
• MAC or DAC
• View based access controls
• Grant and revoke access controls
• Metadata controls
• Data contamination controls
• Input control
• Output control

Web Applications

• Web applications may be connected to internal systems
• Since web applications are numerous and change often, attacks are common and may succeed
• Websites are designed to be easily accessible
• IDS and IPS systems and firewalls are often not employed due to performance or accessibility concerns

Web Application Vulnerabilities

• Most exploited
• Injection
• Broken authentication and session management
• Cross-Site Scripting (XSS)
• Insecure direct object references
• Security misconfiguration
• Sensitive data exposure
• Missing function level access control
• Cross-site request forgery (CSRF)
• Un-validated redirects and forwards

Source:

https://www.owasp.org/index.php/Top10#OWASP_Top_10_for_2013

Web Application Protection

• Hardening web servers and OS (g. MS IIS Servers; Apache)
• Vulnerability scans before deployment
• Using IPS, IDS and Application proxy firewalls
• Remove/secure administrative interfaces
• Authentication credentials should never be hard coded in the app itself
• Input/output validation
• Not just for the app, but for the DB and OS too
• Use random and unique indicators for sessions/cookies
• Encryption must meet industry standards
• Logs/audit trails

Security of API

• API (Application Programming Interfaces)
• A set of rules and specifications that software programs can follow to communicate with each other
• It serves as an interface between different software programs and facilitates their interaction
• API security, and the security of the infrastructures the APIs are running on, is critical to an enterprise that is exposing digital assets
• Employ the same security mechanisms for your APIs as any web application your organization deploys
• Do not pass unencrypted static keys
• Use hash-based message authentication code

Hype Cycle for Application Security

Application Testing

• Unit (module or component) testing
• Focuses on the early examination of sub-program functionality and ensures that functionality not visible at the system level is examined by testing
• Integration testing
• Focuses on the transfer of data and control across a program’s internal and external interfaces
• System testing
• Focuses on demonstrates that all specified functionality exists and that the software product is trustworthy
• Black-Box-Testing vs. White-Box-Testing
• In black-box-testing, the tested system is used as a black box, i.e., no internal details of the system implementation are used
• White-box-testing takes the internal system details (e.g., the source code) into account
• Dynamic Testing vs. Static Testing
• Traditionally, testing is understood as a dynamic testing, i.e., the system under test is executed and its behavior is observed
• Static testing techniques analyze a system without executing the system under test
• Manual Testing vs. Automated Testing
• In manual testing, the test scenario is guided by a human
• In automated testing the test scenario is executed by a specialized application
• Testing during application development
• Static Source Code Analysis (SAST)
• Analysis of the application source code for finding vulnerabilities without actually executing the application.
• Static Binary Code Analysis
• Analysis of the compiled application (binary) for finding vulnerabilities without actually executing the application.
• Fuzz Testing
• Detection of application crashes (e.g., caused by buffer overflows) that might be security critical by sending large random data
• Automated Vulnerability Scanners
• Detection of well-known vulnerabilities, i.e., detection of outdated frameworks and misconfigurations. For this, pre-defined attack patterns are executed, and system fingerprints are analyzed.
• Negative/misuse testing
• Negative testing ensures that application can gracefully handle invalid input or unexpected user behavior
• Typical testing scenarios
• Populating required fields
• Correspondence between data and field types
• Allowed number of characters
• Allowed data bounds and limits

Additional References

• “Security Considerations in the System Development Life Cycle.” NIST 800-64-Rev2
• “Hype Cycle for Application Security.” July 2015
• “Top 10 Secure Coding Practices”. SEI CERT. March 2011
• “OWASP Top Ten Project”. OWASP

Appendix

An Example of Buffer Overflow

• The desired result is to put the attack instructions into memory
• A program that is the target of an attack is provided with more data than the application was intended to handle
• This can be done by diverse means such as entering too much text into a dialog box, submitting a Web address that is far too long, or creating a network packet much larger than is necessary
• The attacked program (target) overruns the memory allocated for input data and writes the excess data into the system memory
• The excess data can contain machine language instructions so that when the next step is executed, the attack code, like a Trojan horse or other type of malicious code, is run
• The malicious code is usually at the end of the excess data Source:http://cis1.towson.edu/~cssecinj/modules/cs2/buffer-

http://cis1.towson.edu/~cssecinj/modules/cs2/buffer-overflow-cs2-java/

Source Code Analysis Tools

• Source code analysis tools are designed to analyze source code and/or compiled versions of code in order to help find security flaws
• Weaknesses
• High numbers of false positives
• Frequently cannot find configuration issues because they are not represented in the code
• Difficult to prove that an identified security issue is an actual vulnerability
• A few open source tools
• Google CodeSearchDiggity, FxCop (Microsoft), RATS, OWASP SWAAT Project

Summary

• Questions?