Security in the SDLC

Kelly School of Business
Indiana University
Information Systems Graduate Programs
SDLC - A Conceptual Overview

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
Security Considerations during Initiation


Security Considerations during Development
  • 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


Security Considerations during Implementation
  • 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


Security Considerations during Implementation
  • 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

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

Operating Systems Vulnerabilities


Application Vulnerabilities

Application Vulnerabilities


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


  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

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

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


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

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


An Example of Buffer Overflow

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:

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


  • Questions?