Application & System Development Security Part 1

Our Achilles Heel Most security devices do not address application security Insecure applications can not easily be fixed without the support of the developer Company could be out of business or developer could be unavailable Company could be out of business or developer could be unavailable Many developers do not properly understand security issues Speed to market demands effects security design Speed to market demands effects security design Many security pros are not developers Exploits can be found after the application has been in production for a long time

Developers Reaction Past three years have heralded a switch from reactive development security to proactive development security Developers pay more attention to security testing Developers pay more attention to security testing Stable patches are released soon after an exploit is discovered Stable patches are released soon after an exploit is discovered Patch “pushes” are now much more prevalent Patch “pushes” are now much more prevalent Disclosure is much more common than a few years ago Disclosure is much more common than a few years ago

Environment Security Risks Application security problems can be exposed by configurations or bugs in the operating system It is very difficult to test applications in every possible environment and configuration Security fixes to the environment can cause unexpected problems with applications The same application can be deployed across an enterprise in multiple environments

Common Environment Issues Lack of input validation on values passed to operating system Leads to system crashes and buffer overflows Leads to system crashes and buffer overflows Validation must be done for data type, format, length Validation must be done for data type, format, length Visual Basic, ASP/VBScipt allow variant type, making type validation even more critical Visual Basic, ASP/VBScipt allow variant type, making type validation even more criticalDefaults Default O/S installations contain many exploitable security vulnerabilities that affect applications Default O/S installations contain many exploitable security vulnerabilities that affect applications Permissions settings, for example, are difficult to correct with installation programs Permissions settings, for example, are difficult to correct with installation programs

Complexity Applications under development constantly become more complex Developers change Documentation is typically not the forte of most developers All of these issues increase the risk of application security problems

Databases Databases typically contain some of the most critical company data Enterprises are moving toward “well connected” databases thereby increasing risks Databases can be connected across the enterprise Databases can be connected across the enterprise Databases can be connected to the Internet Databases can be connected to the Internet Typically, databases are replicated across multiple servers creating more points of vulnerability Typically, databases are replicated across multiple servers creating more points of vulnerability Databases must be backed up which creates media security risks

Typical Database Deployment

Database Integrity Concurrency issues exist with record access and can cause application failures Concurrency issues exist across replicated databases Modern database management systems (DBMS) like Oracle, Microsoft SQL Server support functions for maintaining integrity Rollback – Changes to a DB or record are undone Rollback – Changes to a DB or record are undone Commit – Changes to a DB or record are made Commit – Changes to a DB or record are made Checkpoint – Created to allow rollbacks to restore integrity Checkpoint – Created to allow rollbacks to restore integrity

Database Security Risks Direct electronic data theft Physical media theft Theft by data aggregation Combining lower classification data subsets to create a restricted semi-complete database Combining lower classification data subsets to create a restricted semi-complete database Mitigation – track queries and employ context- dependent classification Mitigation – track queries and employ context- dependent classification Theft by data inference Deriving restricted information based on lower classification data Deriving restricted information based on lower classification data Mitigation – Cell suppression (restricting parts of data), Partitioning (splitting DB into multiple parts), noise and perturbation (inserting unrelated info to mask the data) Mitigation – Cell suppression (restricting parts of data), Partitioning (splitting DB into multiple parts), noise and perturbation (inserting unrelated info to mask the data)

Software Development Life Cycle Project initiation Functional design analysis and planning System design specifications Software development Installation/implementationOperations/maintenanceDisposal

Security Throughout Project initiation User needs and basic security parameters should be defined User needs and basic security parameters should be defined Initial risk analysis should be performed Initial risk analysis should be performed Risk management throughout the process should be defined and implemented Risk management throughout the process should be defined and implemented Functional design planning High level security analysis is done at this step High level security analysis is done at this step

System design specification Access control methods are chosen Access control methods are chosen Encryption and security design is finalized Encryption and security design is finalized Testing plan is finalized Testing plan is finalized Software development Designs are coded Designs are coded Careful attention to input validation and design is a must Careful attention to input validation and design is a must Documentation should be done as the project is coded Documentation should be done as the project is coded Testing of all code should be done per testing plan Testing of all code should be done per testing plan Separation of duties should be maintained to prevent planned security violations and backdoors

Installation and Implementation Configurations should be documented to help control risks Configurations should be documented to help control risks System needs retested to verify that the production environment did not introduce issues not seen in the development environment (called accreditation) System needs retested to verify that the production environment did not introduce issues not seen in the development environment (called accreditation) Security testing should be completed at this point Security testing should be completed at this point Operations and maintenance Ongoing security maintenance and monitoring must be done Ongoing security maintenance and monitoring must be done Security must be reevaluated when major environment changes are made Security must be reevaluated when major environment changes are made

Disposal Data created by the application should be destroyed or secured Data created by the application should be destroyed or secured Media containing data must be properly erased Media containing data must be properly erasedOverwritingDegaussing Physical destruction of media

Change Control System for dealing with changes and modifications to an application Critical for proper control over production source code Helps protect code from unauthorized modification and security violations Allows organized quality control and testing Helps formalize the analysis of impact on security and functionality

Programming Terminology Machine language – commands that can be understood directly by the processor Assembly and high-level languages must be compiled into machine language Interpreters – translate code into machine language on the fly while the application is executing Scripting languages like Javascript and VBScript are interpreted languages Scripting languages like Javascript and VBScript are interpreted languages Compilers – translate code into machine language once when the application is compiled C++, Visual Basic, Java are all compiled languages C++, Visual Basic, Java are all compiled languages

OOPs! Object-oriented programming (OOP) methods are used in most modern programming languages including C++, VB.NET, Java Classes define attributes like variables (properties) Upon instantiation (creation), objects inherit class attributes (inheritance) and add methods (operations) Defined access to methods are called interfaces Objects can also inherit and modify the properties and methods of another object Objects hide functionality and variable values from other objects and code (encapsulation) Polymorphism is when the response of an object to the same request differs by the class it belongs to

Object Brokers Act as middleware to enable objects to run on various servers and platforms Common Object Request Broker Architecture (CORBA) popular in mainframe environments, oldest standard Microsoft’s Distributed Common Object Model (DCOM) now called COM+ in Win2K+ provides similar functionality Java Remote Method Invocation (RMI) provides similar pure Java object brokering

Prototyping Act of modeling interfaces and properties of an object Used as an aid during Rapid Application Design (RAD) Allows an application to execute even though various objects are not complete Is especially useful in group development situations Allows security testing to begin prior to completion of the entire application

Homework Work on group projects