Engineering e Business Applications For Security

IBM Global Services April 2005
Engineering e-Business Applications for Security
By Sharon Hagi, Senior IT Architect, IBM Canada Ltd.
IBM Global Services Page 2
Contents
2 Abstract Application Security 10 Challenges 14 Methods and Recommendations for Application Security Strategies 38 Integrated Application Security Services Model
Abstract
In todays economy, enterprises are evermore dependent on reliable and secure application software to enable their critical business processes. In particular, e-Business applications provide critical linkage between customers, suppliers and partners. Enterprises today have realized that their success will necessitate considerable attention to the security and privacy of their application software, and particularly their e-Business applications. Vulnerabilities and threats related to e-Business application programs can be seen as occurring at all the different levels of the application system, including: denial-of-service attacks proliferating from mal-ware or worms sophisticated application Web Services interface exploits or script-based injections that cripple and damage the application and its data network interception due to protocol weaknesses defeat of encryption due to faulty cryptographic key management or encryption methods database administrators being able to easily steal and sell database content or sensitive configuration parameters application programmers who place undetected malicious code that can cause widespread security failure and can even enable subverted and malicious masquerading of critical business transactions All of these vulnerabilities and threats result in loss of confidentiality, integrity and authenticity. Traditionally, enterprises have prioritized and focused their IT security strategies and budgets on protection of the network perimeter and physical access control to the application system environment. Their goals have been directed at universal elimination of external threats at lower network levels and common infrastructure technical services, as well as through restriction of certain types of physical and logical access to the application. However, the reality today is that these measures are simply inadequate in light of the wide spectrum of threats and vulnerabilities that are seen affecting application systems.
4 The Motivation for
Highlights
Processes can be attacked even when a very good network defense exists
Applications, data and business processes can be attacked even when a very good network and infrastructure security program is in place. For example, good network perimeter defense using firewalls, intrusion detection systems (IDS) and other network security components must still ensure the applications can be accessed by legitimate users and therefore at the same time can facilitate an opportunity for a so-called legitimate user to attack impudently at the vulnerable application interface level. In the same manner in which mature software and systems development organizations engineer for failure to ensure quantifiable degrees of quality and predictable reliability, the notion is that there is a clear need to engineer applications for security. Engineering applications for security is a concept that applies to all the different levels of the application system. Methods include attention to operational and functional policies, processes and standards. Rigorous security conscience design, defensive coding, continual testing, metric collection and monitoring ensure that risks related to application development, maintenance and management are systematically mitigated and reduced as part of a comprehensive risk management life-cycle. This paper contains highlights of methods and recommendations that can be utilized by organizations working through the complex maze of application security. Organizations require a methodical approach as part of a cost-effective enterprise remediation and assurance program to improve security and privacy compliance for their critical e-Business operations.
Attention to operational and functional policies is important
Improve compliance for critical e-Business operations.
Highlights
Applications are designed, developed, and maintained by a variety of business units
The Motivation for Application Security

Enterprise businesses depend on a wide variety of applications to run day-to-day operations. Applications are designed, developed, and maintained by either the IT group or individual business unit IT teams within functional groups. Applications can also be third-party applications, purchased and in some cases specifically customized for the requirements of the line of business (LOB) or the enterprise. Many of these applications, including web-based applications, so-called rich-client applications, mobile applications and others are rife with vulnerabilities, ranging from their susceptibility to SQL injections and cross-site scripting to internal attacks on application systems and subsystems by employees/insiders at the various stages of development, operations and maintenance. Market research firms such as IDC estimate that worldwide spending on application development specifically in Web Services-based software projects will reach $11 billion by 2008, compared to $1.1 billion in 2003. A recent Gartner survey of 110 companies also revealed that 54 percent are already working on new web services applications this year and are planning on starting new projects soon. Securing these applications and the data they manage has grown in significance and complexity and is now a formidable task facing many organizations. We are primarily motivated to consider application security for several different reasons but among the principal ones identified are: Risk management Regulatory compliance Corporate reputation and public image Cost of redesign/reengineering due to security failure Hacker activity statistics
Survey of 110 companies also revealed that 54 percent are already working on new web services applications
Highlights
Manage risks throughout the application development lifecycle
Risk Management
Organizations need to understand their exposure and sensitivity to security events as they relate to development, maintenance and management of applications. This understanding leads to appropriate strategy and allocation of budget and spending on security to offset and mitigate the risks. Organizations have been focusing typically on applying risk management subsequent to application development and deployment. The focus of risk determination in such cases has been largely on the network and the shared IT infrastructure supporting the application and, to a lesser degree, on the processes involved in designing and developing the software. In addition, there is often a need to have metrics available to understand scenarios and risk measures particularly relevant to applications and their management. In absence of these instruments, development organizations have gaps in their risk management and their appreciation of their complete risk picture. The deficiency is due to incomplete analysis of exposures, scenarios and potential loss to the business, attributed to security failures of the application itself and/or the application development process. Methods devised to address the gaps clearly require the use of quantification and benchmarking to assess and measure risk due to security concerns introduced during the design or coding of an applications (e.g. insider attacks). Unfortunately, we have observed that this kind of risk management shortcoming is indeed widespread in the market place and have concluded that in many cases it serves to explain why market analysts continually report on the lack of strategic focus and often insufficient budget allocations to deal with risk specifically in the application security context.
Risk scenarios and measures for applications need to be defined
Highlights
Regulatory Compliance
The legislative landscape and the resulting regulatory requirements place increasing emphasis on the role of corporate governance with respect to application software assurance. The tenets of regulations such as Sarbanes Oxley specify that corporate governance, which is principally composed of executive management, be responsible for providing transparency, integrity, and accountability over regulated financial reporting and data. While the subject matter of information security is not specifically discussed within the text of the act, the reality is that modern financial reporting systems are heavily dependant on applications and their associated security controls, processes and audit-ability. Any review of internal controls would not be complete without addressing controls and processes specifically around application development and maintenance. An insecure application system would not be considered a source of reliable financial information because of the possibility of unauthorized transactions or manipulation of financial data. In the eyes of auditors, there is no clear distinction between applications that help run the business (e.g. billing systems) and applications that help service the customers (e.g. e-store, medical electronic records, etc.) Other regulatory requirements with focus on application security and privacy include the Health Insurance Portability and Accountability Act of 1996 (HIPAA), Gramm-Leach-Bliley Act (GLBA), EU Data Protection, Basel Accords (Basel II guidelines promulgated by the Bank for International Settlements), Bill 198, Personal Information Protection and Electronic Documents Act (PIPEDA) and other Canadian Privacy Laws. Regulatory requirements have specific implications on organizations developing and managing applications in their e-Business environment. Compliance is non-trivial when considering the complexities of modern and highly distributed application systems.
Financial reporting systems are dependent on applications and their associated security
Highlights
Security vulnerabilities in applications can have large business impacts
Corporate Reputation and Public Image
Negative publicity about security vulnerabilities in applications impacts potential sales and plays a major role in eroding user confidence in not only the products but also the companys value-add services. For financial institutions, insurance companies, medical, transportation, utility and telecommunications firms the impact can be rather devastating. Application security events resulting in customer data being lost, financial data being compromised or altered, medical records exposed, even cyber-terrorism and crime can all damage customers and shareholders confidence and impact business growth potentials for a substantial period of time. In addition, one might also consider that in light of increasing government regulatory pressures, any incident, even a relatively minor one, may indeed flag the organization for some closer attention from compliance auditors. Security advocates in mature software and systems development organizations often attest to the fact that it is exponentially more expensive to fix a ruined reputation resulting from an application security failure than it is to build the right processes and methods that could have caught and fixed the exposure that lead to the failure in the first place.
Cost Of Redesign/Reengineering Due To Security Failure
Fixing a ruined reputation is exponentially more expensive than building in application security
Costly defects can be traced to deeply rooted design flaws or process shortcomings
The cost to companies needing to continually fix various vulnerabilities and security flaws in systems and application portfolios is significant. Loss of revenue is one cost component but more importantly, in many cases, companies have had to postpone significant strategic initiatives and divert considerable investment capital in order to revamp their application security posture. Since most serious security defects can be traced to deeply rooted design flaws or process shortcomings, there is a realization that to truly address security, companies need to fundamentally look at their software security architecture and design and even more so, focus their security re-engineering efforts on the development processes.
Highlights
Effective and practical application development and management security needs to be appropriately prioritized and consideration must be given to questions such as: Is there sufficient thought given to costs involved in continually fixing applications for security vulnerabilities? What are the costs involved in a possible re-design/re-engineering of processes and applications should they fail an audit? What are the cost saving in addressing security at the early requirements and design stages? What are the risks to the company in accepting application security status quo? More often than not, security for applications is viewed as an ancillary aspect, something that can be retrofitted later on. There is also ample evidence from organizations such as the Carnegie Mellon Software Engineering Institute (CMMI) to suggest that in an analogous manner to software defects, security defects and related concerns are far easier and significantly cheaper to fix when they are uncovered and addressed in the early steps of the development process. Applications have to be designed systematically for robustness and for security as early as possible so as to reduce the costly need to redesign and re-engineer when its not really practical or economically feasible. The following chart illustrates the exponential cost increase to correct detected security defects with respect to the development and maintenance phase in which the defect is discovered.
Applications have to be designed systematically for security
Source: IBM Corp.
Highlights
75% of attacks against websites and web-based applications come at the application layer
Hacker Activity Statistics
A recent Garner report states that over 75% of attacks against websites and web-based applications come at the application layer and not lower infrastructure and network layers. If e-Business organizations place all their efforts and trust in good network security but not as much effort toward their application security, they are in actuality missing key risks and therefore have critical business gaps. From observed hacker malicious activity statistics, we know that hackers are now seldom interested in defeating the network or the infrastructure low-level defenses. The adversaries today are well aware of the fact that applications are typically less defended than the rest of the IT infrastructure. For example, hackers may be interested in directly probing and discovering unsafe SOAP method implementations to pass in SQL script injections based on known database vulnerabilities. Exposed XML Schema often makes it extraordinarily easy to postulate how a specific attack can in fact be structured. In other examples we see skilled hackers employ rather clever social engineering tactics to entice and recruit employees with sensitive roles to obtain artifacts such as unprotected XML configuration files for J2EE application servers. The information in those files is often sensitive enough and can be used to gain levels of access and enable unauthorized deployment of application components.
Skilled hackers exploit exposed application-level information to gain access to systems and data
Highlights
Challenges
There are several challenges in mitigation of risks in application systems and development processes which effective strategies must take into consideration: Complexity Cost Skills Compressed time-to-market Monitoring Application security incident response
Complexity
Vulnerabilities need to be managed in more than one type of platform, framework and configuration
Managing vulnerabilities in todays largely heterogeneous and highly distributed application systems is a significant task. There is a need to manage vulnerabilities in more than one type of platform, framework and configuration. There is a need to manage vulnerabilities from third-party software, components and subsystems. There is a need to manage vulnerabilities in the software the enterprise develops itself. Since applications are really part of the automated manifestations of business processes, there is little to suggest that one will be similar to another. Each one is more or less unique and therefore must be treated and addressed separately from a security perspective. The shear number of combinations, variations and configurations is enough to cause major concern over how to really tackle and deal with this undertaking in any costeffective manner. The answer is that there are, of course, methods and processes that do help and we shall examine some of them more closely.
Cost
Spending on IT security is significant, and needs to be targeted effectively
Most businesses today have a specific budget allocated to IT security. IDC has reported that while larger organizations traditionally tend to spend the most money, smaller companies today are surprisingly allocating a fair portion of their IT spending on security. The question often asked by CIOs (Chief Information Officers) and CSOs (Chief Security Officers) is whether or not the budget allocation is effective at addressing the risk comprehensively.
Highlights
As we saw earlier, with gaps in risk management as it relates to application security, there is no quantification of risks and therefore we can expect that budgets may not appropriately align to address application risks in a manner typically expected by senior management. Perception in the industry is also that application security tends to be an expensive business undertaking. There is little appreciation of the real cost saving because of lack of metrics collected over the life-cycle of a business application. Using metrics and statistical methods on observations would indicate overall cost of a stressful event in the life-cycle of an enterprise application verses the cost of developing the application with the ability to either prevent the event or successfully recover from it.
Skills
Required application security skill sets are in short supply in the market place
Engineering security into applications and associated processes and methods involves a wide range of roles and skills, including: Application security architects Developers with specific security and cryptography training Security platform, product and integration specialists Security assessment experts (system certifiers, product evaluators, ethical hackers and auditors) Security system administrators This combination of skill sets is in short supply in the market place and organizations are challenged to manage those valuable resources on an on-going basis in terms of career development and other HR issues. Outsourcing and contracting out work to a trusted third party specializing in security for application development and maintenance can be a practical solution to many of the skills acquisition, supply and management issues.
Compressed Time-To-Market
Pressure to beat competition and be first to market is not a new challenge
The continuous pressure to beat competition and be first to market is not a new challenge. If history is a guide, the challenges facing development organizations in transitioning to higher maturity levels (e.g. Capability Maturity Model levels) has always been the fear that increasing process and documentation overhead would slow things down and hence harm the companys potential profitability.
Highlights
When planning to incorporate security into the processes and development life-cycles the very same reaction is to be anticipated. Overwhelmed by the overabundance of implied processes and plans, an organization may draw back from adopting application security practices. Like any other maturity based engineering model, the application security engineering model includes requirements to document processes and procedures and to follow up with reviews and testing to ensure they are performed as documented and mandated by policy. While a number of processes, plans, and other types of documentation will be required, and hence overhead will be incurred, careful planning and choosing the right kind of risk management process will ensure the most effective size and priority of the investment in these activities. A single security plan may meet the requirements of many process areas within a typical development organization. In more complex cases a longer term, multi-phase transition plan may be required. In many cases the process re-engineering is not as revolutionary as some may see it. It really emphasizes the same common sense practices that have been implemented for software quality assurance for many years.
Monitoring
Implementing application security requires careful planning
Monitoring efforts must be designed in conjunction with efforts to collect and analyze process metrics
Throughout the application development and maintenance security processes it is necessary to measure progress and monitor for success. Methods include processes that can be used to validate the appropriateness of and compliance with written policies, processes and business control measures designed to address application security. Typically, monitoring efforts must be designed in conjunction with efforts to collect and analyze process metrics. The metrics are quantifiable aspects that are used in assessment and risk management activities to compare against pre-determined benchmarks.
Highlights
Responding to security incidents requires analyzing and evaluating large amounts of information
Application Security Incident Response
A significant challenge for enterprises managing application systems and operations is how to organize a response to application security incidents. Security information, even when it is compartmentalized into one area, involves sifting through large amounts of information in real-time. In a complex enterprise, there are alerts from firewalls, intrusion-detection systems, application audit trails, database logs, messages from operating systems, etc. All of which need to be analyzed and evaluated before an appropriate response can be formulated. In many organizations, this has led to the institution of a Computer Security Incident Response Team. Other organizations have outsourced the monitoring of key elements of their application security infrastructure and let outside agencies handle the first-response duties.
Security is not and cannot be a cookie cutter process. There is no magic pixie dust that can be sprinkled over a protocol to make it secure. Each protocol must be analyzed individually to determine what vulnerabilities exist, what risks they may lead to, what palliative measures can be taken, and what the residual risks are. S. Bellovin, AT&T Labs Research, RFC 2316, Report of the IAB Security Architecture Workshop
Highlights
Engineering security into application systems is a critical discipline
Methods and Recommendations for Application Security Strategies

Engineering security into application systems is a critical discipline and should be a key component in multi-disciplinary, concurrent or distributed development teams. This applies to the development, integration, operation, administration, maintenance and evolution of e-Business application systems as well as to the development, delivery, and evolution of software-based products. Security concerns are addressed throughout the development and maintenance life-cycle. Competencies and capabilities can be delivered as tools, systems, products or as a collection of processes and services. In general, the key steps involved in application security strategies involve: Gaining a quantified understanding of the security risks associated with an enterprise e-Business application Establishing a balanced set of security requirements in accordance with identified risks Transforming security requirements into security controls and process guidance to be integrated into activities of development disciplines and methodologies employed on a development project and into the definition of system configuration, operation and maintenance goals Establishing confidence or assurance in the correctness and effectiveness of security mechanisms using assessments, reviews, testing and certification Determining impacts due to residual risk associated with security vulnerabilities in a system or its operation which are determined acceptable
Highlights
Source: IBM Corp
IBM has introduced an Integrated Application Security Services model
The focus at IBM has for many years been one that covers the breadth and depth of the discipline of engineering security into software. IBM, through its numerous product development arms and research laboratories around the globe, has produced some of the most advanced methods, tools and products that cover a broad range of application security aspects. These range from code analysis, testing tools and sophisticated risk management systems to process engineering, systems and software architecture and security consulting methods delivered by IBM Global Services. This paper focuses on key methods showcased in a number of services being offered as part of the Integrated Application Security Services model recently introduced by the Security/Identity & Privacy Practice in conjunction with the Application Management Services (AMS) and Application Innovation Services (AIS) groups within IBM Global Services.
Highlights
Typical strategies for mitigation employing the IBM services focus on these key areas in addressing e-Business application security: Complying with Regulations Development and Maintenance Life-Cycle Processes and Methodologies Training and Awareness Monitoring and Security Intelligence In the following sections we provide several important highlights of methods and recommendations that enterprises can leverage to enhance their application security efforts and provide deeper insight into issues that may need to be considered.
Complying with Regulations
By examining compliance strategies devised by IBM for its customers using audit guidance such as the Control Objectives for Information and related Technology (COBIT) from the Information Systems Audit and Control Association (ISACA), we are able enumerate several key recommendations as they relate to application security controls and processes.
Security Policy for compliance, there needs to be evidence in the form of
A comprehensive and well-communicated security policy is fundamental
written and comprehensive policy that addresses application development and maintenance business requirements. A security policy is something very fundamental for any organizations security program. While most security cognisant organizations do have some form of policy, in many cases we have found it did not document managements desire or criteria as it relates to the effort of developing, deploying and maintaining critical business functions implemented in computer software. In addition, there needs to be clear evidence of effective policy communication to developers, administrative and operational staff.
Security Standards for compliance there needs to be evidence of the
Development security standards are required for compliance
existence of appropriate security standards related to the development environment (e.g. tools, platforms, components etc.). Standards are typically collections of system-specific or procedural-specific requirements that must be met by everyone involved in the development, deployment and maintenance of an application.
Highlights
A broad range of application security controls are required
Architecture, Design and Implementation of Security Controls - Fundamental controls for applications with impact on financial reporting or privacy and confidentiality of an individuals private records such as medical records, involve ensuring that only people who are authorized to use an application can access it. And once they do, they are able to use the application and data in a manner that guarantees confidentiality and integrity as well as ensures there is continual monitoring and auditing of everything transpiring that has any impact on the companys compliance with the regulations. This includes controls in the following areas: User account management; provisioning; activation; change control enforced at the application level. Authentication, Authorization and Auditing (AAA) assurance Credential storage and management Use of cryptography to facilitate authentication, protect confidentiality and integrity of data and provide forms of non-repudiation for transactions and critical activities. Protection from mal-ware and viruses Resiliency - ability to detect security conditions and ensure that further actions by the user or the application will not adversely impact the data or the business process integrity. Continuity ability to detect service failure arising from possible security events and rely on redundant capabilities to recover operations without adversely impacting data or the application. Segregation of Duties Whereby it is demonstrated that sufficient segregation is in place, enforced by the application system as well as within the software development life-cycle (SDLC), so that no single person involved has the capabilities required to control, monitor and audit any process from start to finish.
Highlights
Effective monitoring must be capable of detecting security issues affecting the application
Monitoring Evidence must be provided that application systems are being
effectively monitored for security events. Effective monitoring, which according to guidelines must be capable of detecting security issues affecting the application, requires the use of correlation analysis, intelligence and the appropriate tools and statistical techniques. Examining network logs for application attacks is often not effective if the application is not designed to report or capture the right type of event information. For audit purposes, it is important to design and document monitoring goals that focus on timely identification of security issues affecting the application and the creation of action plans to address those issues.
Physical Security while physical security is outside the scope of this paper,
we feel compelled to mention that compliance and audit readiness will involve steps to ensure that physical access to the application infrastructure and systems supporting the application development processes is appropriately restricted, controlled and monitored. General guidelines range from a simple lock and key to controls as sophisticated as biometric identification systems and multi-factor authentication. Establishing the physical boundaries can be difficult in todays distributed computing application environments. A data center supporting the enterprise business systems may have very strong security controls, while a remote site or office may simply not have the same levels of control. A principle of security would dictate that security of an application system, as a whole, is only as strong as the weakest link. In this case the concern may be that an adversary can choose to attack the application indirectly using the less secure remote site/office as a launch pad. In either case, auditors will be examining and ensuring that physical access to the systems is restricted uniformly and access is monitored and reviewed on a periodic basis.
Security of an application system, as a whole, is only as strong as the weakest link
Highlights
Software is not just code
Development and Maintenance Life-Cycle
The application software development life cycle (SDLC) is a conceptual model used mainly in a software engineering and project management context that describes the stages involved in the applications development project and subsequent maintenance. When we get into security issues surrounding the SDLC we cannot avoid talking about what software really is. The ANSI/IEEE Standard 610.12-1990 defines a standard glossary of software terminology. It includes software product definitions of: Development Program Development Project Plan Requirement Specification Architecture and Design Description Source Code Object Code Test Plans User Documentation Hence, software is not just code. Consequently, security and assurance methods or activities should not be exclusively focused on reviewing source code or practicing defensive coding techniques alone, as they will likely not lead to a secure application! In general, nearly all SDLC methodologies, to some degree, follow steps that include: Project Requirements and Planning; Product Requirements and Specification Analysis; Architectural or High-level Design; Detailed Design; Coding and Unit Testing; System Testing; Production, Operation and Maintenance. Various SDLC methodologies have been developed since the early days of computing to guide the processes involved, including the waterfall/ V-shaped model (arguably the original SDLC method); rapid application development (RAD); joint application development (JAD); the spiral model; Rational Unified Process (RUP) and many other examples with different variations on the theme.
Highlights
Security assurance methods apply throughout the SDLC
To better illustrate how specific security assurance methods work within the SDLC, we employ the classic V-shaped model. While this model may not necessarily be the best or even the most popular model, it is well understood, which makes it an excellent illustration tool to show the basic quality assurance processes involved in most SDLC models and how they map back to the early planning, design and implementation phases. The following diagram shows the progression of application development life-cycle activities in the classic V-shaped model:
Source: IBM Corp.
Processes and procedures for security are placed within these unifying life-cycle frameworks. They are incorporated as gateways, checkpoints and qualifying steps to ensure that risk reduction and appropriate controls are being addressed prior to transitioning to subsequent phases. In addition, metrics collection and audit functions can be closely integrated so that analysis can occur throughout the processes, and monitoring can establish how well the development and maintenance process are meeting the security objectives of the enterprise as well as the applicable regulations.
Highlights
A Threat and Risk Assesment must be conducted
Requirements and Planning
During this phase, activities are required to review and ensure that security policies are updated and include application security and development interests. In addition, this phase is an ideal launch pad for initiatives targeted at the applications regulatory compliance and audit objectives. Security standards are revisited and reviewed to ensure they contain appropriate specifications for software development and maintenance (e.g. hardware, software, environment access, build tools, platforms, etc.). Standards for security components and protocols need to be defined using, for example, standard profiles for security controls, where some of the following criteria can be considered: Interoperability what standards and profiles are necessary for interoperability with other platforms, peers and partners? Topology how will application components be deployed and distributed and will that have any impact on selection of standards and profiles for controls? Manageability and Ease of Use what is the impact on user experience? Accountability what monitoring facilities and methods will need to be considered? Performance what impact will the standards have on overall performance requirements? Confidentiality, Integrity and Audit-ability Requirements and planning phases fundamentally have to include some form of threat and risk assessment (TRA) as part of the enterprise risk management framework. A TRA is conducted to determine principal business risk exposures and mitigation requirements for the application. The TRA examines information assets that are being impacted and handled by the application as well as the assets composing the application system itself (e.g. components, databases, APIs). These assets are subject to a sensitivity analysis which uses vulnerability and threat information and correlates this information to scenarios and benchmarks. This is performed to determine the likelihood of occurrence and impact severity, and provide prioritization, mitigation recommendations and quantification of the residual risk. The TRA process feeds specific mitigation requirements and criteria into
A threat and risk assessment must be conducted
Highlights
ensuing phases for design and implementation. It is recommended to employ standard risk management methods and emerging industry standards such as the IEEE Std. 16085 Software Engineering: Software Life Cycle Processes, Risk Management. There are also a number of additional security tasks that require attention during the project management and project planning stages: Security clearances and qualifications of resources assigned to the project Segregation of duties and the impact on project scheduling and costs Security of the development environment o How sensitive information is communicated and handled by staff and external parties (e.g. secure email, instant messaging or other forms of collaboration tools) o Source code repository and documentation management system access control and protection o Configuration management database, provisioning and deployment/ distribution systems security o Development workstation security o Build and testing environment security controls
Architecture and Design Methodologies and Activities
Numerous security tasks are required during project planning and management
Similar to any software and systems engineering discipline, there is a need to promote order and consistency in the way the enterprise develops security controls and solutions for e-Business applications. A consistent approach is required to provide the technical guidance for developing security architectures with clear linkage to other disciplines involved in the design, creation and operation of the application. In addition, risk management, security strategies and business requirements need to have specific delineation and integration points as there needs to be logical flow from the threats, vulnerabilities and risk to the counter measures, security controls and patterns which are designed as part of security architecture and design activities.
IBMs Method for Architecting Secure Solutions (MASS) is a good example of a solution design methodology
IBMs own Method for Architecting Secure Solutions (MASS) is a good example of a solution design methodology incorporating the requirements of security engineering for applications. In fact, MASS is the basis for much of the application security architecture and design services available from
Highlights
MASS is a comprehensive framework used by consultants and security architects to develop application security architectures and design guidance
IBM Global Services. MASS is soundly based on Common Criteria (ISO 15408) and therefore contains the most comprehensive statements of security related design requirements. The methodology is not security architecture in itself, but a comprehensive framework used by consultants and security architects to develop application security architectures and design guidance. Principal functional and operational design guidance and blueprints are broken down according to five security subsystems, which in turn are further broken down to components and finally into nodes that are the aspects needed for low-level design activities. The five security subsytems are categorized as: Trusted credential subsystems where enrollment and management of credentials and identities take place. Access control subsystems where specific decisions on authentication and authorization are made by the application. Information flow control subsystems where coordination of assurance information and security protocols takes place. Integrity subsystems where specific cryptographic functions ensure things such as secure messaging using encryption and secure hashing, interfacing with security hardware to protect secret keys, digital signatures for signing data and more. Audit subsystems where application activities and events are captured, stored and reports can be generated on information concerning security significant decisions within the application
Source: IBM Corp.
Highlights
At a high-level, the architecture and solution design activities related to application security can be seen as applying in all levels of the enterprise e-Business application framework and infrastructure, including hardware layers, network services, distributed object communications and messaging, management application framework services, common services including identity, authentication and authorization, business process and transaction orchestration, and so on. Processes and methods work in conjunction with SDLC, risk management, monitoring and metrics activities and phases to ensure the incorporation of security controls and assurance in every layer and every subsystem of the application. As seen in the following process diagram, baseline application security requirements, derived from business requirements analysis, regulatory control objectives and specific risk management activity outputs, including vulnerability assessments, risk assessment and corresponding asset profiles, are used to form security and privacy controls and mitigation requirements. Security architecture principals, design patterns, policies and standards are used to derive the security solution outline. Collaboration of architects and designers in other disciplines is critical to ensure seamless integration of the solution into the applications overall design.
Collaboration of architects and designers in other disciplines is critical to ensure seamless integration of the solution into the applications overall design
Source: IBM Corp.
Highlights
Focus on physical design and cryptographic-oriented systems development
Architectures, patterns and best practices are good at providing solutions at higher levels. Security low-level solution design activities provide more detailed blueprints and design specification for platform and technology dependent application security components and nodes. They also include low-level cryptographic details on how crypto APIs, toolkits, protocols and specific hardware and/or software components are to be integrated. The activities in application security low-level solution design also focus on physical design and cryptographic-oriented systems development. Dedicated cryptographic solution design is needed, for example, if the application requires use of specific low-level security and crypto services not available or accessible in the environment and not found in any offthe-shelf solutions. It is also needed in cases where requirements call for functionality such as custom secure application level messaging, specialized encryption key management and other customized security related controls. In e-Business applications, the application itself is but the manifestation of the use cases or processes that implement business logic. Much of the enabling functionality and facilitation of services are provided by the application framework. The application framework is a construct supporting the business logic and provides all the necessary services using technologies and components, such as middleware services (e.g. J2EE containers); content rendering and user interfaces (UI) such as .NET clients, Web content, wireless application gateways, etc.; databases; identity management and directory services; PKI certificate services; protocol gateways (e.g. Web Services adapters), legacy services connectors (e.g. IMS/CICS/JCL), virtualization management, clustering and load management; operating system platform services, storage area networks (SANs) and others.
Application frameworks support business logic and provide all necessary services
Highlights
The following diagram illustrates some of the many constructs involved in application frameworks which are the main focus areas in design activities.
Source: IBM Corp.
Security low-level designs will be quite pervasive in the application framework
Undoubtedly, much like the architecture, security low-level designs will be quite pervasive in the application framework. Many development organizations producing high assurance application solutions on COTS framework components have addressed some of the following security structures within the framework:
Structures and design for Credential Issuance and Management
Integrated PKI services helping users obtain and manage their digital identities using certificates Multi-factor authentication and policy-based conditional access control components and subsystems Secure storage of sensitive credential data (e.g. password encryption or hashing, private key protection using hardware security modules (HSMs), bio-metric patterns data protection, etc.)
Highlights
Structures and design for Flow Control
Transaction integrity measures that prevent transaction replay, masquerading, repudiation or unauthorized modification Communications confidentiality using encrypting protocols such as transport layer security (TLS), Internet protocol security (IPSec), XML-Encryption, XML-Signature, cryptographic message syntax (CMS) S/MIME, etc. Legal bearing non-repudiation mechanisms using digital signatures, trusted time services, user-transaction contract management principals
Structure and design for Privacy
Granular data access control policy enforcement
Encryption of persistent data in databases and files Granular data access control policy enforcement provide a form of privacy-based access policy enforcement, which ensures that authorized parties can only access and view information which they are permitted to access based on privacy legislation, policies or contractual obligations. Information collection, processing and distribution management, logging and auditing for privacy regulatory compliance
Structures and design for Access Control
Identification, Authentication and Authorization
Identification, Authentication and Authorization - these are hot topics today, especially in the area of Web Services applications. A number of competing standards and methods are available but the intent is to facilitate identity management, authentication management via single sign-on (SSO) or reduced sign-on (RSO) and communication of security assertions containing things such as privileges between applications using federated trust services.
Structures and design for Auditing, Monitoring, Integrity and Resiliency
Designing highly available and guaranteed transaction logging
Logging and tracing facilities designing highly available and guaranteed transaction logging; secure activity and event logging that prevent sensitive data (e.g. user credentials or account numbers) from being included in operational logs (e.g. in violation of privacy policies or regulations).
Highlights
Coding and Building
Security activities in the coding and building phases are mainly focused on the following: Safe coding Secure configuration handling Reviews Building (compiling, linking and packaging) with security Application of defensive/secure coding practices ensures that software modules are developed to address known vulnerabilities. Practices involved include techniques and methods for memory and buffer management that prevent overflow, techniques and methods for input validation checking, correct and safe use of APIs, safe remote invocation, safe metadata and interface definitions, correct use of cryptographic toolkits and security functions and so on. Tools and computer aided software engineering (CASE) products are available and can help at all levels of the design and development process, including specialized code analysis tools that, in many cases, integrate into the Integrated Development Environments (IDEs) (e.g. WebSphere Studio, Microsoft's Visual Studio or Borlands JBuilder) and work in conjunction with CASE tools such as Rational Rose, Purify, Quantify etc. Secure handling of application configuration information is something that is often overlooked by many development organizations. It may surprise some to find out that many developers can leave highly sensitive configuration items, such as database users and passwords, in configuration files that can be viewed without restriction by anyone and are therefore a serious exposure. Specific methods and techniques are required to ensure safe handling of configuration files and parameters to reduce such exposures. Code reviews and peer reviews are arguably the most important processes that are most frequently advocated by mature development organizations. According to available statistical data1 , testing alone finds one defect per 4 hours staff lab time. Formal review/inspection finds one defect per 1 staff hour. Hence security reviews are a very effective tool for revealing coding errors and security coding issues/exposures as compared to testing.
Secure coding practices ensure that software modules are developed to address known vulnerabilities
Security reviews are a very effective tool for revealing coding errors and security coding issues/exposures as compared to testing
1 Based on data from documented results from ISO certified companies who have attained a minimum SEI Level 2 (or better) designation; IBM, Hewlett Packard, Motorola, Boeing etc.
Highlights
The goal of the reviews is to detect security problems (potential security defects) as close as possible to their point of origin. The earlier a security problem is detected, the easier and cheaper it is to fix it. The process should involve extensive metrics collection to track and document sources of errors and defects, leading to improvement of both the application and the development process. The bottom line is that, reviews improve not only software quality but also security. Fix security errors early = Fix security errors cheaply!
Use a combination of both automated code analysis tools and process frameworks
Here too we see the use of a combination of both automated code analysis tools and process frameworks to develop effective security code review methods and processes. As a general guideline, code review methodologies should concentrate on correct, efficient and defensive/secure coding techniques, and usage of: Method calls and input validation (e.g. cross-site scripting, SQL injections) Class structures Code reuse practices and use of dangerous APIs Networking Correct SPRNG (Secure Pseudo Random Number Generators) seeding Device drivers Infrastructure access Protocols Encryption Methods/performance/administration Scoping and name space issues to reduce errors resulting in security issues Data access controls Memory management (e.g. buffer overflow protection) Access to OS functions and admin APIs Port mapping Exception and error handling Tracing and debugging issues as they relate to exposing sensitive data Logging Configuration and provisioning management Cryptographic methods and implementation
Highlights
Obfuscation techniques Administration Patching and upgrade methods 3rd Party API integration Compilation and other code build issues OS authentication Garbage collection Java
Security activities involved in the build processes
Security activities involved in the build processes, which include things such as compiling, linking and packaging for deployment, include: use of code obfuscation tools to prevent certain degrees of reverse engineering of object code which can lead to exposure of sensitive information embedded in the code itself (e.g. initialization data such as crypto initialization parameters or sensitive intellectual capital) application of technologies and methods to deal with issues around trusted software distribution and updates (e.g. signed code), digital rights management (DRM), trusted computing, licensing and so on.
Testing and Security Controls Validation
In later phases of the SDLC, the focus shifts from designing and building security controls to validating that the security controls will be effective. Execution of testing and validation activities in the SDLC is preceded by the definition of appropriate testing plans that correspond to all aspects relevant to use cases, the application component model, and the operational model. The following diagram illustrated processes involved as an example in how effective testing plans are created.
Source: IBM Corp.
Highlights
Testing plans incorporate specific guidelines for the following types of testing activities: Unit Testing Integration Testing System Testing Certification/Accreditation Unit testing guidelines specify the source-level security functional verification criteria that are the responsibility of the developer/programmer. For example, unit testing would specify how a developer is to verify that a particular code segment executing data encryption is actually encrypting the data in the correct and expected manner. Integration testing guidelines support component-wise system integration as well as cross-organizational integration and interoperability testing that focuses on security aspects. For example, such testing would be conducted between development teams working in a B2B Web Services project where the teams collaborate in order to execute tests designed to verify security functions of interfaces and messages passed between the applications. System testing guidelines take the user view as well as the adversary view of the application. System testing involves testing all of the implemented use cases and user interaction models to see if any avenues or exposures exist that could permit a user to override security controls or even defeat them. Ethical hacking techniques and penetration testing are an integral part of building more comprehensive test plans. Certification testing typically involves an independent accreditation thirdparty and is a final step toward achieving industry security assurance certification for standards such as the Common Criteria (ISO 15408), Europay, MasterCard, Visa (EMV) standard, Federal Information Processing Standard (FIPS), Federal Information Security Management Act (FISMA), Defense Information Technology Security Certification and Accreditation Process (DITSCAP) and others.
Ethical hacking techniques and penetration testing are an integral part of building more comprehensive test plans.
Highlights
Production, Operation and Maintenance Most standard organizations identify four types of maintenance where specific security assurance activities are integrated: Adaptive Maintenance modification of an application because of some changes to its external environment or requirements Corrective Maintenance - modification of an application to correct a defect or security vulnerability Perceptive Maintenance - modification of an application to enhance its functionality, hence potentially impacting security assurance Preventative Maintenance - modification of an application to anticipate a problem and ease future maintenance A major element of on-going maintenance activities involves continual vulnerability and risk management processes, security testing and re-certification to ensure the continued security assurance levels of the application system. Among the testing activities included we can find, for example: Application Security Controls Testing a type of validation testing that focuses on applications conformance to security requirements using black-box, data-driven or I/O-driven security testing. The test plans are derived from system testing plan guidelines. Application Security Vulnerability and Risk Assessment and Review white-box or logic-driven testing designed to uncover systematic or process security defects. This type of testing is based on detailed knowledge of software design and implementation and can occur after the code has been changed to add a new feature, or perform fixes. The test plans are derived from integration and system testing plan guidelines. Application Security Error-Oriented and Component-Oriented Testing focuses on assessing the security resiliency and recoverability of the application in the event of error conditions such as memory overflow, storage capacity limit attainment, network outage, OS or hardware faults. This type of testing is necessitated by the potential presence of errors in the maintenance processes leading to security vulnerabilities. The test plans are derived from unit testing plan guidelines.
On-going maintenance activities involve continual vulnerability and risk management processes, security testing and re-certification
Highlights
In addition, we see the growing importance of integrating automated testing, vulnerability scanning and discovery systems that test the application on a regular and continual basis and can be used to report on any discovered vulnerability points, unsecured services, security and privacy policy violations, unprotected resources, exposed sensitive data etc., in a continual way.
Metrics
A metric is a quantitative measure that characterizes an attribute of: The application software development process The quality and security assurance process A software product or application system. To help determine how good the enterprises efforts are at achieving their assurance goals for application security we see the appropriate inclusion of activities needed to collect metrics data effectively throughout the SDLC and operational life-cycles. It is recommended that, at the very minimum, metrics are collected and analyzed to provide some idea of the possible issues around the development of the application: number of lines of code found with security errors, function points with possible input validation concerns, feature points missing security test plans, effort size (staff months, man years), etc. Metrics are essential in those areas where we need most control of our security efforts and processes. Some traditional approaches in structuring metrics include: Application Code Security Metrics: used to identify security quality of application code Metric: Number of Security Defects per module or package of similar size/complexity. Perspective: Total Released Security Defects (Development perspective) vs. Customer Found Security Defects (Customer perspective) Application Secure Development Process Metrics: used to identify quality of SDLC security processes and their QA. Metric: In-process security faults per module or package per phase/process. Containment Effectiveness (per phase and total)
Metrics should be collected throughout the SDLC and operational life-cycles
Application Code Security Metrics
Application Secure Development Process Metrics
Highlights
Maintenance Metrics
Perspective: Phase Containment Effectiveness, Total Security Defect

Containment Effectiveness. Maintenance Metrics: used for assessing security processes around the maintenance environment Metric: Number of New Open Security Problems, Total Open Security Problems, Age of Open Security Problems, Age of Closed Security Problems, Cost to Fix Security Problems, Mean Time To Repair, Mean Time To Isolate, etc. Reliability and Resiliency Metrics: used to identify and predict application failures due to security faults Metric: Failure rate, TBF Time between Failures, MTBF Mean Time between Failures Estimation Accuracy Metrics: to determine the viability of estimates for application security Estimation Accuracy Developer Metrics: used to measure or define an indication of application security properties Modularity and compartmentalization of code for which indication of following the proper defensive coding principals can be a guide to the overall survivability of modules and subsystems in the event of a security event. Complexity measures which assess the goodness of security in a structured design: Coupling - the degree of critical interdependence of each pair of elements. Cohesion - the degree of tightness of each element, communication cohesion. Information hiding - the degree to which low-level details are hidden in the elements. Code complexity measures which assess the complexity and understandability of the source code. Simplicity inevitably leads to more secure applications. The more complex and less understandable the code is, the less secure it can be.
Reliability and Resiliency Metrics
Estimation Accuracy Metrics
Developer Metrics
Highlights
People are really the most important component of achieving desired security at any level
Training and Awareness
As seen for application security, the power is clearly in the process. However, people are really the most important component of achieving desired security at any level. For an application security assurance program to be successful, it is necessary to create a security culture where employees, contractors and partners are educated on security policies, specific processes, why security is important and what behavior is expected of them. Most employees will do the right thing if they know what it is, and most employees have a very specific role to play within the development and operational aspects of the application for security to be achieved. A training and awareness program will obviously need to include technical aspects that aid in the design and implementation of secure applications. Approaches such as safe coding practices, defensive and resilient design patterns are only a sample of the possible technical topics that staff will need to be aware of and trained in. A general strategy will also determine if a custom education program needs to be developed and maintained internally or outsourced to a third party. For example, development of technical application security training courses could be an aspect left best to a subject matter expert third party company, whereas internal process and policy education and awareness can be designed, developed and delivered by the enterprises IT Security Organization. In addition, there may be a need to examine education delivery options for course material. Depending on the need and complexity of the material, computer based training and/or instructor-led material should ideally be incorporated. We also recommend closely examining the implementation of a specific secure application development certification process for developers and administration staff. Employees with these critical roles should require a certificate attesting and validating their knowledge of necessary security requirements.
Development of technical application security training courses
Employees with critical security roles should undergo a certification process
Highlights
Effective monitoring requires the use of correlation analysis, intelligence and use of tools and statistical techniques
Monitoring and Security Intelligence
Application security events should be monitored throughout the life-cycle. Depending on the size and complexity of the application system and infrastructure, a very large amount of security event information may be generated. Effective monitoring requires the use of correlation analysis, intelligence and use of tools and statistical techniques. Regardless of the scope of security monitoring, the result should be identification of security issues and the creation of action plans to address those issues. Monitoring of collected metrics for processes related to the SDLC and maintenance are also important. Metrics monitoring criteria are required to define specific triggers which will drive timely response to certain negative patterns which will require immediate or high priority attention. For example, suppose that for a certain e-Business application it is of value to measure the number of times security vulnerabilities failed to be identified or captured during code review processes. This metric may indicate the code review processes are not as effective as they should be in capturing these issues. The development organization must be capable of identifying weaknesses and provide plans designed to remedy the deficiency in the process or the method being monitored. Security intelligence for applications is meant to collect, analyze and disseminate information designed to equip the enterprise with the necessary tools to effectively mitigate and resolve threats involving and affecting application systems infrastructure on a continuous basis. IBMs new Security Intelligence managed service is an example of a service that provides critical advisories and information for the risk management and application life-cycle processes. The service provides specific data collection on today's global complex technical security environment where this data is then analyzed and converted into specific threat mitigation knowledge, making it a powerful tool in developing application specific mitigation and counter measures on an on-going basis. The goal is to stay ahead of adversaries and indeed market competitors.
Metrics monitoring criteria are required to define specific response triggers
IBMs new Security Intelligence managed service provides critical advisories for the risk management and application life-cycle processes
Highlights
Application security engineering and development methods can help achieve business application assurance goals.
Conclusion
We have seen a significant array of activities and issues that are involved in application security carried out throughout the SDLC. It is important to emphasis that while this may seem overwhelming to many inexperienced enterprises, a combination of expert guidance, effective risk management and crisp definition of security business strategies will help prioritization and steer IT spending capital to achieve the business application assurance goals. Continuous improvement, reusability, measurement and monitoring of the security processes and practices will promote consistency, cost savings and ultimately will lead to the success of the application security engineering and development methods and consequently the expected reduction in the amount of application security related incidents.
Highlights
Integrated Application Security Services Model

In an effort to help customers address security for e-Business applications, IBM has expanded its security services offerings, with an emphasis on security vulnerability assessment, security process development for the application SDLC, security architecture and solution design and implementation as well as managed services including Security Intelligence and Incident Response support.
IBMs integrated services model for application security
The integrated services model for application security is possible due to the strong partnership between the IBM Global Services Security/Identity & Privacy Practice and Application Management and Innovation Services (AMS/AIS). In addition, through collaboration with industry best-in-class partner companies, IBM is able to bring together comprehensive application security services and leading edge technologies, tools and capabilities. IBM Global Services is uniquely positioned to deliver these services due to its access to the IBM software product development and research arms from which security and privacy (S&P) consulting lines of business draw vast capabilities.
Highlights
In-depth review of specific processes and controls around the application development and maintenance life-cycles
The following is a synopsis of the services offered:

Application Security Process Review
This service provides an in-depth review of specific processes and controls around the application development and maintenance life-cycles. It is particularly effective at going to sufficient depth to verify that security controls intended to be in place have processes in place to ensure they are implemented. The review is typically conducted against predefined application security process standards and best practices such as ISO/IEC 17799, benchmarks and maturity capability models such as SEI CMM/CMMI,SA-CMM and SSE-CMM. The processes are reviewed or inspected along all aspects of the development life-cycle process. The emphasis is incorporation of specific risk processes into broader engineering and assurance processes.
Application Security Process Development
Apply best practices to design and develop specific application security processes
By employing strong process development methodologies such as the IBM ITPM methodology, IBM Rational Unified Process model (IBM RUP), SEI CMM/CMMI, SSE-CMM maturity model goals and ISO/IEC 17799, this service identifies best practices to design and develop specific processes that can be infused with the application development life-cycle model in use by the customer, and provides the introduction of security controls, checkpoints, monitoring, metrics and audit capabilities to ensure application development processes are secure end-to-end.
Application Security Architecture
Customized application security architecture based on sound principles and standards
Every enterprise developing secure e-Business applications will need at some point a consistent method to design and conceptualize an application security solution and architecture. Be it for packaged or commercial off the shelf (COTS) software that requires extensive customization or perhaps a new J2EE or .NET application, the enterprise architecture and in particular the security architecture, should be based on sound methodologies, security design patterns and best practices. IBM consultants analyze the business and application strategies as well as any existing security policy throughout the clients enterprise, or a subset of the enterprise, and provide application security architecture principles that can be used to make management and technology decisions consistent with the organizations
Highlights
application security objectives. Methodologies are based on Common Criteria (ISO 15408), ISO 7498-2 for technology recommendations and ISO/IEC 17799 for process recommendations. The customized application security architecture will provide a comprehensive, standards-based framework for managing the application security program and ensuring that it is consistent with the business objectives.
Secure Application Solution Design
Design and implement application security controls and subsystems
Implementing security at any level can be complex, even more so when considering security system design. Aspects that require considerable engineering attention and cryptographic expertise when designing a security system are addressed in this service. Advanced encryption techniques, cryptographic key provisioning, management and exchange, tamper-proofing persistent data and databases, conditional access control, digital signatures, secure email, signed code and trusted computing, integration of smart cards, biometrics and advanced hardware security modules and crypto acceleration solutions are just a few of the many application security controls and subsystems IBM consultants can help design and implement.
Application Security Code Reviews
Review source code using analysis tools and manual walkthroughs to validate the security of application software modules
This service provides and facilitates review processes for source code using analysis tools and manual walkthroughs to validate the security of application software modules. The reviews are offered in a wide range of programming languages and development platforms. The service is also aimed at inspection of security protocol design and implementation, security metadata, interface definition, information hiding, obfuscation, configuration data usage and more.
Highlights
Ethical hacking and application penetration testing
Application Security Testing
The focus in this testing and assessment service is on the application design and implementation as opposed to the processes. The testing and assessments focus on the application itself, interfaces (web content, web services and GUI), subsystems, integration and aggregation points, transient data, transactions, platforms (concrete or virtualized), networking services employed and any database or operating platform services. The incorporation of ethical hacking and application penetration testing throughout provides a hands-on component which works well with the entire assessment framework for both legacy, new (developed) and third party components.
Application Security Controls Review
Identifying the security requirements
This service provides a "health check" type of assessment of general application security controls. IBM consultants review the application security controls from a broader organizational perspective. The service includes identifying the security requirements (policy, standards, procedures, including those to meet its legal requirements, ISO/IEC 17799 and other ISO standards), what is in place, what is currently missing or weak and what can be done to improve it. The service is typically useful to customers who are seeking to get a snapshot of their application development security maturity and what gaps they have in their high level architecture, design and processes.
Application Security Risk Review
Threat and Risk Analysis geared towards application security posture and software engineering process
Risk review and assessment is a vital element of the enterprise application security program. This service provides a TRA methodology using industry standards such as IEEE 16085 specifically geared towards the measurement of the applications security posture and the software engineering process involved in its construction and validation. Starting with identification and enumeration of assets, data and business transactions and processes handled by the application, consultants will determine sensitivities, conduct scenariobased analysis and provide reports indicating exposures, including potential legal and regulatory compliance exposures. The assessment will also test the security controls of the application and identify areas that require additional controls enhancements, process improvement and investment prioritization and strategy for the vulnerable assets.
Highlights
IBM Global Services Learning provides a broad range of security education and awareness services.
Learning Services
IBM Global Services Learning provides a broad range of security education and awareness services. An extensive library of classroom and e-learning courses is available to help customers build critical application security competencies and keep development and operational staff skills up-to-date. Services range from Security Engineering Practices, Security Clinics for J2EE and .NET developers to Hands-on Security Qualification Testing and Advanced Penetration Testing for the Ethical Hacker.
Intelligence Services
IBM Security Intelligence Services is part of the Managed Security Services portfolio
IBM Security Intelligence Services (ISIS) is part of the Managed Security Services portfolio and is a key component of keeping our customers up to date with the latest advisories, vulnerabilities and threats related to platforms, middleware, COTS components and development tools.
Biography
Sharon Hagi, Security/Identity & Privacy Practice, IBM Global Service, IBM Canada Ltd, 3600 Steeles Ave. East, Markham, Ontario, L3R 9Z7 (shagi@ca.ibm.com). Mr. Hagi is a Senior Architect in the Security and Privacy service delivery organization at IBM Global Service. He received his Hon. B.Sc. in Computer Science and Physics from the University of Toronto. Mr. Hagi has a solid background in the telecommunications and software industries. He has worked on a range of information technology projects including multi-channel applications for mobile banking, brokerage and m-commerce, financial risk management large-scale analytical engines, software engineering and design for telecom equipment and development of high speed switch fabrics for Frame Relay and Asynchronous Transfer Mode WAN protocols. He was in charge of leading technical engineering groups for security product development including firewalls, smart card applications and embedded hardware security modules. He has also led a security services and professional consulting practice in Canadas leading cryptography technology firm. He was involved in specification and design of security solutions for distributed and ubiquitous computing application frameworks, integrating wireless access security technologies, 3G cellular mobile intelligent communication systems, WLAN, WMAN and satellite networking, as well as advanced public-key enablement (PKI) concepts for which Mr. Hagi holds a number of international patents. Subsequent to joining IBM in 2003, he became lead architect for application security consultancy projects. Mr. Hagi is a member of the Institute of Electrical and Electronics Engineers and the Association for Computing Machinery.
References
[1] Christopher Fox, CA and Paul Zonneveld, CISA, CA, IT Control Objectives for Sarbanes-Oxley, Issued by IT Governance Institute [2] Systems Security Engineering Capability Maturity Model, SSE-CMM, Model Description Document, Version 3.0, June 15, 2003 [3] Dunsmore, and Shen, Software Engineering Metrics and Models, the Benjamin/Cummings Publishing Company, Inc. 1986 [4] Application Security Best Practices at Microsoft, The Microsoft IT group shares its experiences, White Paper Published: January 2003 [5] Huaiqing Wang and Chen Wang, Taxonomy of Security Considerations and Software Quality, COMMUNICATIONS OF THE ACM June 2003/Vol. 46, No. 6 [6] J. J. Whitmore, A Method For Designing Secure Solutions, IBM Systems Journal - Vol. 40, No. 3, 2001 [7] IEEE Std. 16085 Standard for Software Engineering - Software Life Cycle Processes - Risk Management [8] ISO/IEC Std. 17799 Standard for Information Technology Code of practice for information security management
Copyright IBM Corporation 2005. IBM Canada Ltd. 3600, Steeles Ave East Markham, ON L3R 9Z7 Printed in Canada 04/05 All rights reserved. IBM and the IBM logo are trademarks or registered trademarks of International Business Machines Corporation in the United States and are used under licence by IBM Canada Ltd. Other company, product and service names may be trademarks or service marks of others.

Engineering e Business Applications For Security

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Engineering e Business Applications For Security

Hochgeladen von

Copyright:

Verfügbare Formate

IBM Global Services April 2005

Engineering e-Business Applications for Security

By Sharon Hagi, Senior IT Architect, IBM Canada Ltd.

IBM Global Services Page 2

4 The Motivation for

IBM Global Services Page 3

Attention to operational and functional policies is important

Improve compliance for critical e-Business operations.

IBM Global Services Page 4

The Motivation for Application Security

IBM Global Services Page 5

Risk scenarios and measures for applications need to be defined

IBM Global Services Page 6

IBM Global Services Page 7

Corporate Reputation and Public Image

IBM Global Services Page 8

Applications have to be designed systematically for security

Source: IBM Corp.

IBM Global Services Page 9

Hacker Activity Statistics

IBM Global Services Page 10

Spending on IT security is significant, and needs to be targeted effectively

IBM Global Services Page 11

Pressure to beat competition and be first to market is not a new challenge

IBM Global Services Page 12

Implementing application security requires careful planning

IBM Global Services Page 13

Application Security Incident Response

IBM Global Services Page 14

Methods and Recommendations for Application Security Strategies

IBM Global Services Page 15

Source: IBM Corp

IBM has introduced an Integrated Application Security Services model

IBM Global Services Page 16

A comprehensive and well-communicated security policy is fundamental

Development security standards are required for compliance

IBM Global Services Page 17

IBM Global Services Page 18

Monitoring Evidence must be provided that application systems are being

Security of an application system, as a whole, is only as strong as the weakest link

IBM Global Services Page 19

Development and Maintenance Life-Cycle

IBM Global Services Page 20

Source: IBM Corp.

IBM Global Services Page 21

Requirements and Planning

A threat and risk assessment must be conducted

IBM Global Services Page 22

IBM Global Services Page 23

Source: IBM Corp.

IBM Global Services Page 24

Source: IBM Corp.

IBM Global Services Page 25

IBM Global Services Page 26

Source: IBM Corp.

Security low-level designs will be quite pervasive in the application framework

IBM Global Services Page 27

Structures and design for Flow Control

Granular data access control policy enforcement

Identification, Authentication and Authorization

Designing highly available and guaranteed transaction logging

IBM Global Services Page 28