1 1 Cyber-attacks frequently take advantage of software weaknesses unintentionally created during development. This presentation discusses some ways that improved acquisition practices can reduce the likelihood of exploitable software weaknesses appearing in a delivered system or software product. This presentation assumes that you have some experience with creating software system requirements to meet business needs and an understanding of system development lifecycle phases.
3 3 The introduction covers the recent changes is security threats and the effect those changes have on how we protect systems.
4 4 Cyber-attacks have significantly changed over the last 10 years. In the late 1900s, the success of an attack might be measured in the number of sites compromised. Today, an attacker might devote weeks, if not months, to find a way to compromise a specific site. Well-resourced, highly skilled, and persistent attackers have compromised organizations such as Google and the highlyrespected security supplier RSA. RSA was a secondary target. The primary objective was information at a Lockheed Martin site on the F-35 aircraft. Lockheed Martin used software from RSA to authenticate its employees for access to its computing systems. The attackers compromised RSA to obtain copies of employee authentication data so they could log into the Lockheed Martin site. While the consequences of recent attacks have been significant in terms of the loss of intellectual property and trade secrets, those attacks obtained sufficient access to adversely affect the operations of the compromised organizations. The same kind of attacks could degrade the operations of government systems. Attacks frequently exploit a software weakness inadvertently created during development, which is what we call a vulnerability. We refer to them as software weaknesses rather than software
5 5 errors, because the system behaves as expected under normal operating conditions but can be adversely affected under unexpected conditions created by an adversary. Reducing the frequency and severity of such weaknesses requires improved supplier development practices and acquisitions that select suppliers with such capabilities.
6 6 Moat-like defenses that use external security controls such as firewalls and encryption can be effective defenses for attacks that target the network. But attack targets change as weaknesses are eliminated. Application software is now a popular attack target. An analysis of successful software attacks identified over 900 kinds of software weaknesses. The capabilities of highly skilled adversaries who can exploit known weaknesses or find new ones in increasingly complex computer systems have surpassed the defensive capabilities of external security controls. We have a situation similar to rollover risks for early models of sports-utility vehicles or SUVs. There are no significant problems driving a SUV under normal conditions, but there are circumstances such as swerving to avoid an accident where a SUV because of its higher center of gravity has a greater risk of rolling over than a sedan has. The rollover risk cannot be mitigated by adding controls after a SUV is manufactured. The risk is reduced by a redesign where electronic vehicle controls intervene when sensors report conditions that could lead to a rollover. In a similar fashion, we need to reduce the likelihood and severity of exploitable software weaknesses during development rather than by adding controls later. Such a change in strategy
7 7 is reflected in the latest version of the NIST security control document. Security is now a combination of building it right and implementing specific security controls. Building it right or Building security in means that compromises and defenses are considered during all phases of the development lifecycle. We cannot verify that a system was built right after development is completed. Rather we need to find ways to assess the system at various points during the lifecycle so we are confident that development is on track to meet the build it right objective at completion.
8 8 We show how an objective to build it right affects acquisitions and, in particular, show that activities in the early phases of an acquisition lifecycle can support that objective. Software assurance in general considers conditions that could lead to unexpected behavior. We concentrate on those conditions that could lead to a security failure which are described by the trustworthiness component of software assurance. The most important objective is to show that knowing how to analyze security threat using a practice called threat modeling can improve system requirements and supplier selection criteria.
9 9 The NIST Risk Management Framework can help acquirers analyze the consequences of risks and possible mitigations for them. The top tier can address strategic risks by defining policies to govern the implementation and design of the work processes and the associated information system. Tier 1, for example, could establish certification requirements for acquisitions involving critical information systems. The bottom tier is the operational layer, which contains the computing systems and manages the tactical risks that only affect that level. A critical aspect of a risk assessment is to understand the interactions between Tiers 2 and 3. The work processes inherit the computing system risks, but the computing requirements for the work process can increase system security risks.
10 10 Let s expand on the connection between tiers 1 and 2. Acquirers and suppliers both do risk assessments. The acquirer is concerned about the business impact of a compromise and the threat agents that could target a system. A supplier concentrates on system risks and monitors the software weaknesses that have been exploited by successful attacks. Acquirer risks include poor supplier development practices which increase the risk of a compromise. But a supplier s development risks can be increased by an acquirer s functional and operational requirements. Thus, we have a feedback loop between acquirers and suppliers. We describe a practice called threat modeling can be used by a supplier to analyze and mitigate security risks inherited from requirements. A general understanding of threat modeling can also help acquirers understand how their actions can affect the development of secure software.
11 11 In this section, we discuss threats and threat modeling.
12 12 Threats are used in two ways for security. A threat can refer to the agent that executes an attack or to the consequences of an attack, that is, the attacker's objective. The Microsoft STRIDE threat model identifies six consequences of an attack. This presentation considers the three threats that are most closely associated with software vulnerabilities. We cover data tampering, disclosure of information, and an elevation of privilege. The last one is often the most important one to an adversary.
13 13 An elevation of privilege does not directly damage a system, but it often provides an attacker with the necessary privileges to access or modify data. In this slide and the next one, we describe an elevation of privilege that was the first step in the RSA compromise. The objective of the RSA attack was to obtain employee authentication data for organizations that purchased RSA software. Assume the data is not Internet accessible and managed by the application in the upper-right corner of this slide. The first step in the attack is to access the internal RSA network. The RSA attack started with a well-crafted message to an employee in business services. That included a link to what appeared to be useful business information. Of course, the employee should have ignored such an , but a mail message created by an expert using specific employee information obtained from sites such as LinkedIn can be very convincing. The link in the was to a malicious website. When the employee s browser accessed that web page, a vulnerability in a browser add-on for videos let the attackers install their own programs and become insiders with the same access to data and programs as the employee had.
14 14 Most likely, multiple attempts had been made to access the network, and the one described in this example was the first one that worked. If it had failed, a persistent attacker would have tried other options, and with an attacker with expertise and patience would likely succeed. Most likely, multiple attempts had been made to access the network, and the one described in this example was the first one that worked. If it had failed, a persistent attacker would have tried other options, and, with sufficient expertise and patience, such an attack would likely succeed.
15 15 If we are considering the design of a home security system, the thief is now in the house, and sensors should have reported that entry. But in this example, intruders use the identity of a trusted employee to avoid being reported. Internal software systems frequently assume a safe computing environment. But an attacker with access to the internal network can apply sophisticated and likely unanticipated attacks to compromise internal software components and obtain access to additional accounts. Each compromised account could provide access to additional systems and data. The attack does not have to compromise the targeted system if one of the compromised accounts has access to it. Securing a system requires more than just security of the critical components. A weakness in a secondary component can give an attacker a sufficient foothold to eventually compromise the system.
16 16 Threat modeling refers to the threat analysis that is done during design in Microsoft s Secure Development Lifecycle. Its objective is to identify how a design could be compromised before the code is written. The details for how to do that vary among developers, but it is a common objective among organizations that incorporate security into their full development lifecycle. Identifying weaknesses early with threat modeling can result in better security than improving development reviews or security testing. Such reviews and tests only attempt to identify such weaknesses after they have been created. An acquirer does not have to do threat modeling. So what are the benefits for having a general understanding of it? Say you ask a contractor about delays in task completion and the response from the contractor is a query such as Do you really need to do this? For security, this response could mean that the security risks associated with a functional requirement cannot be fully mitigated or that the implementation of the required mitigation will increase costs or delay delivery. If your response is no, that requirement can be removed, but a response of yes, may require you to accept the security risks in order to have the desired system feature. Or it might force you to make changes in the schedule, costs, or other requirements so the design can be revised to reduce the security risk to an acceptable level. An acquirer, who recognizes early in the
17 17 acquisition lifecycle that the requirements could lead to problems with the security analysis, can tailor the source selection criteria to identify suppliers with the security capabilities needed to manage the anticipated complexity. That complexity also requires an acquisition to have a source for security expertise to monitor and evaluate the security aspects of system development.
18 18 There are multiples ways to respond to a risk. A commercial organization might accept a computing risk associated with a business practice where the increased sales compensate for higher risk. An organization can use an insurance policy to transfer a risk to its provider. Unfortunately, a supplier could also transfer the risk of exploitable software weaknesses it created to those organizations that follow it in a supply chain and eventually to the acquirer. In this presentation we consider how risks could be mitigated.
19 19 We now introduce threat modeling as one way for an acquirer to better understand the feedback loop between acquirers and suppliers that we have described. In the next few slides, we describe three risk factors that are analyzed using threat modeling and show how acquirer requirements can affect those factors. Acquirers who understand these interactions can anticipate the security issues that could arise during development.
20 20 The left side of this diagram lists the steps involved in Microsoft s threat modeling. We numbered the steps we cover in this presentation. Steps 1, 2, and 3 are the risk factors considered by threat modeling. Steps 4, 5, and 6 analyze those threats to determine the system risks and feasible mitigations. We start with step 1, then steps 2 and 3, and finally steps 4, 5 and 6, and we alternate between a developer s and an acquirer s perspective.
21 We start with business requirements. 21
22 22 A use case is a way of writing a business requirement. It describes system behavior when it responds to an external request, that is, it can describe an information exchange between a user and a system. We will apply threat modeling to the use case shown on this slide. Customer information is managed by a database server. A database record includes a customer identifier, a 5-digit numeric value, and customer information such as a name and phone number. The business requirement described by the use case is that the input of a 5-digit numeric value CLICKS displays a web page with the ID, name, and phone number for the customer with that ID. A use case is a risk factor because a software weakness in its implementation could provide an adversary with access to business resources such as the customer database in this example. Thus, this use case increases the risk for threats such as data tampering or information disclosure that target that database. Thus a key question for the acquirer is whether the use case as implemented by the supplier can be compromised.
23 23 The developer develops an information flow that meets the business requirements described by a use case.
24 24 In the next two slides, we show an implementation of an information flow for our use case and then describe how that implementation could be compromised. Access to customer information is managed by the database server. That server accepts queries to access or modify data that are written in a special-purpose programming language. Many commercial database products use what is called the Standard Query Language with the acronym SQL. A software application on the web server accepts the user input and uses it to create a SQL command that retrieves the ID, name, and phone number for the record with that ID. Such a query might look like this statement where the user input is inserted at the end. The database server executes that command and returns a table with the desired values. An attacker will attempt to exploit the connectivity created by this implementation of the use case.
25 25 A misuse case is a sequence of actions that can harm a system. Whereas a use case describes what a system should do, a misuse case describes what it should not do, that is, a misuse case is a security requirement. The misuse case for this example is a vulnerability called a SQL Injection, which frequently is at the top of lists of the most dangerous vulnerabilities. A misuse case for this example is a data exchange that starts with the value shown. Why would attackers try such a value? An attacker knows the implementation could create a database query written in SQL that includes the submitted value. The attacker s objective is to modify that query by inserting valid SQL constructs into the input. That s why it s called a SQL injection. The expression or(1=1) that has been inserted for this misuse case is a valid SQL expression. A SQL injection succeeds only if the software application fails to verify that the input is free of SQL expressions or, in this case that the input consists of 5 numeric digits. Maybe the programmer did not verify the input values as it was assumed that the database server respond with a record not found message for invalid ID values. But the command constructed by the software application using this input value is a valid query. Since the where condition is always true, the database server returns a table that contains the ID, name, and phone number for all entries. Variants of this compromise have been used to retrieve credit card data. Skilled attackers
26 26 have used SQL injections to change database entries. This misuse case is an example of an attacker using the connectivity with the user to exploit and compromise the database server.
27 27 We have a tug of war between security and system features where the outcome can help the attacker. A feature we call extensibility is a prime example. On the web, extensibility lets Yahoo and Google develop separate applications and retail vendors design interfaces to their own sales systems. An extensible industrial process control computer can be used by the purchaser to control an assembly line, a power generator, or traffic lights. But such extensibility also enabled the RSA compromise and an attack called Stuxnet that damaged more than 1,000 Iranian centrifuges at a nuclear facility. The web is good example of extensibility. When it was first created, a web page had data, instructions on how display that data, and links to other pages. The initial objective was to access information, rather than to read or make purchases. As the use of the web grew, organizations wanted to be able to add functionality without modifying the browser. A solution that s been applied in similar situations is to add processing instructions to the data feed. In other words, the web page contains data and processing
29 29 Analyzing use cases can provide an acquirer with valuable information. As we just showed, any critical business asset on the information flow for a use case is a possible target for an attack. We noted in the last slide that requirements for features such as extensibility increase the risk of a compromise. That risk might be reduced by using a commercial product where the developer explicitly considered how that feature could be compromised. A one-off custom implementation could have software weaknesses that a commercial developer had identified and avoided. The threat knowledge required should be included in the supplier selection criteria. Supplier s often have in-depth knowledge of the potential software weaknesses and attack patterns only for some domains such as financial systems, or for technologies such as those used for mobile access and industrial process controls. For example, the expertise that can avoid web server compromises is not necessarily applicable to a general purpose information system.
30 30 Next, we consider the two other risk factors considered by threat modeling. Compromises can arise from information we do not know about external systems, and system integration may have to contend with mismatches in the security assumptions made by the system components.
31 An adversary can exploit a weakness in an external resource to compromise the targeted system. In particular, external data sources are a significant risk because they provide a way for an attacker to submit values that could compromise a system. A system can depend on existing infrastructure services such as using the operating system to verify that a user is authentic. In our example, the system depends on the integrity and availability of a shared data store. 31
32 32 Secure network communications is an example of a security assumption. All software makes implicit security assumptions, for example by assuming the validity of a user so as to avoid repeated requests for an account name and password. An organization s security policy could require that a user be authenticated at a particular point in an information flow. Attacks frequently exploit unverified assumptions such as data validity which is a security risk as we saw in the SQL injection example. Whereas we only verified a user at selected points in an information flow, data validity has to be repeatedly checked. Invalid data can result from a software error rather than an adversary action. A security assumption that cannot be verified is a significant risk. For example, the designs for systems only used within an organization have often assumed that the internal network would not be accessed by an adversary an assumption we cannot verify. But with the success that expert and well-resourced attackers have had in obtaining network access, an increasing number of organizations assume the internal network will be compromised.
33 33 Next, we consider how an acquirer s requirements can affect the external dependencies and security assumptions that must be managed by the developer.
34 34 We combine the discussions of dependencies and security. Dependencies such as data sources or use of an acquirer s infrastructure services are often system requirements. Those dependencies have their own security assumptions. The required software functionality may be best provided by a commercial product, but the security assumptions for such software are not always known. Commercial off-the-shelf, or COTS, software may not be designed for high-assurance usage. Commercial developers have to balance the effort devoted to the threat resilience with competitive factors such as time to market and cost. The required threat resilience may have to be provided by how that product is integrated into the system. System integration may have to resolve security issues arising from the use of consumer computer devices such as tablets and cell phones. Security assumptions always arise for use cases that require data exchanges among independently developed and managed systems. The security assumptions are often not known and for externally managed systems can change without notice. How trusting should such a data exchange be? Has an external system been compromised? A security assumption such as trusting
35 35 a user whose identity was authenticated on a remote system requires careful analysis. For such data exchanges, the supplier selection criteria should include secure integration capabilities.
36 36 A supplier that is doing threat modeling uses the information collected on the risk factors to identify probably system risks and their mitigations. This step has to involve system stakeholders to prioritize the threats and make trade-off among business consequences, cost of mitigations, and system functionality. A supplier s development decisions have to be consistent with an acquirer s acceptable level of risk.
37 37 How can a supplier mitigate threats? This chart maps threats to the possible targets for that threat. An attacker seeking information might want to monitor network traffic or access a data store. An attacker with access to the network or a data store could modify data. Certainly access to a network or a data store could enable an attacker to limit access to a system.
38 38 We can use external security controls to mitigate threats that target network links or data stores. Examples of external controls include user authentication and access control, encrypted network links, and encrypted data stores.
39 Software can be a threat target. A SQL injection exploits a software weakness to access information and can also be used to modify data. The compromise of the RSA employee is an example of an elevation of privilege enabled by a vulnerability in a browser plug-in Software is a target for all six STRIDE threats, which increases the importance for developing threat resilient software. 39
40 40 An attacker can only exploit vulnerabilities in software on the information flows that process data they can submit, that is, data from external sources. Applications with access to critical assets require attention. But the continued occurrences of SQL injections suggest that such risks are too often ignored during design and implementation. Web browsers are a target because of their extensibility. The most recent web standard for HTML includes a long list of options such as support for multiple video formats. The implementation of a web page that has a data exchanges starts with defining the use cases that describe the exchanges, and the security assumptions and dependencies for the software that implements the use case. That software could reside on the web server or be included in the web page code to be executed by the browser. The number of possibilities can overwhelm threat modeling. An attacker can only exploit vulnerabilities in software on the information flows that process data they can submit, that is, data from external sources. Applications with access to critical assets require attention. But the continued occurrences of SQL injections suggest that such risks are too often ignored during design and implementation. Web browsers are a target because of their extensibility. The most recent web standard for HTML includes a long list of options such as support for multiple video formats. The
41 41 implementation of a web page that has a data exchanges starts with defining the use cases that describe the exchanges, and the security assumptions and dependencies for the software that implements the use case. That software could reside on the web server or be included in the web page code to be executed by the browser. The number of possibilities can overwhelm threat modeling.
42 42 As we noted earlier, external controls such as data encryption and network controls have been used to mitigate the risk of vulnerabilities. But the mitigations for many of the 900 identified software weaknesses must be done by the system software. Identifying threats and their appropriate mitigations must be done as part of the system development lifecycle. A number of organizations have executed security initiatives to reduce the number and severity of software weaknesses that appear in their software. The Build Security in Maturity Model is a joint effort by Cigital and Fortify to catalog the security activities for a collection of large organizations with such an initiative. Fifty-one organizations had been surveyed by the fall of One observation from the analysis of the BSIMM surveys is that the organizations with the most mature development practices had a strategic commitment to delivering secure software. What does that mean? Such a commitment includes incorporating security into the full development lifecycle. For example, design practices consider possible compromises; those doing detailed design and coding are aware of potential threats and recommended mitigations; and test plans include software weaknesses and the effectiveness of the system mitigations.
43 43 But a strategic commitment requires more than improved development practices. An organization with a strategic commitment has allocated sufficient resources to maintain its core knowledge of attacks and mitigations. The software functions with significant security risks might be developed by experts and then be made available in shared libraries to the application development teams. Such organizations incorporate appropriate standards. A key measure of a strategic commitment is reflected in an organization s governance practices and policies. Have all developers received training on writing secure software? Have security checkpoints, milestones, and signoffs been established at various points in the development lifecycle to ensure consistent and effective application of the lifecycle practices? A security signoff at various times during development ensures that someone has accepted responsibility for security.
44 Next, we discuss how to apply aspects of threat modeling to the acquisition lifecycle. 44
45 45 In this section, we show how knowledge of the interactions between requirements and a developer s threat analysis could be used. We use an FAA project done in 2009 as an example. The FAA objective was to create an external web site that provided current commercial flight information to non-government organizations. An internal FAA system was the source of that data.
46 46 Acquisition requirements should consider possible threats. For this example, the data on the web site could be modified. A more serious threat is that an attacker gains access to the web server and uses that access to compromise the internal FAA system. That internal system may have assumed a very trusting operational environment. But for this example, the FAA system should not trust the web server, that is, it should assume that adversaries have accessed it.
47 47 If we have a medical condition that requires surgery, we seek a specialist. The risk of data tampering requires a supplier with knowledge of compromises associated with data exchanges such as SQL injections. There is a very sophisticated attack community that target web servers. Hence, suppliers should be very knowledgeable about known web site compromises. A supplier s staff must be capable of writing secure web applications. The possibility of compromising the FAA internal systems increases the importance of source selection. In addition to having web security expertise, a supplier for this example should know how an information system like the FAA system could be compromised. This aspect of development might require cooperation between the supplier and those who know the design and security assumptions for the FAA system.
48 48 Supplier selection criteria have to identify suppliers with the experience and capabilities needed to test the system. For example, security testing frequently includes penetration tests in which a skilled attack team tries to compromise a system. For this example, a penetration team experienced with web attacks should attempt to compromise the server. But the most significant threat is an attacker with web server access who compromises the internal FAA system. The penetration team now has access to the web server. This team is likely different from the first one because its members should have experience in compromising large information systems rather than web servers. Finally, it is critical for the acquisition strategy, source selection, procurement contracts, and so forth to enable the acquiring organization to access the artifacts produced by the development practices. For example, an acquirer could require that the supplier provide the results and analysis of the penetration tests to confirm that testing considered possible compromises.
49 We conclude with a summary. 49
50 50 The overall objective is to reduce the frequency and severity of unintentional software weaknesses created during development. In this presentation, we suggested several ways that such risks could be identified early in the lifecycle. Building security in includes anticipating threats but also incorporating security into the full development lifecycle so that possible weaknesses are identified early. But risk reduction also depends on understanding the security risks of software features and system usage. The improved development practices that support building security into a system also have their limits. Ross Anderson is a highly respected computer scientist and security engineer. In an interview, he was asked about the progress being made for security engineering. He noted that over the last 30 years, developers have been provided with improved tools and methods for developing systems, but the percentage of development failures has stayed around 30%. Better tools encouraged the development of larger and more complex systems and also created more dramatic failures. We have a similar situation for security engineering. Threat modeling can remove known weaknesses, but having a large set of system requirements also increases the threat factors that must be considered by the supplier. The additional complexity can create new vulnerabilities, increase the possibility that known weaknesses could be missed, and force system stakeholders to accept higher security risks.
51 51 Practices such as threat modeling help us reduce the likelihood of a malicious compromise but cannot eliminate the possibility of one. Continuous monitoring of system behavior is necessary. Attack techniques and exploitable vulnerabilities evolve, but the consequences as described by STRIDE are constant. We need to build security controls into a system such as strong user authentication, encryption, and auditing that reduce the likelihood of an information disclosure and be able to recover from an attack that tampered with critical assets. Security can be improved if we do not focus exclusively on malicious intent. We may only know after an incident that a problem with data integrity was the result of malicious data tampering and not the result of an accidental user action not anticipated by system designers. The intent should be secondary to mitigating and recovering from possible failures. System capabilities such as rapid recovery that increase resiliency to operational, software, and hardware failures also improve resiliency to a security compromise.
SPEAR PHISHING UNDERSTANDING THE THREAT SEPTEMBER 2013 Due to an organisation s reliance on email and internet connectivity, there is no guaranteed way to stop a determined intruder from accessing a business
Protecting Your Organisation from Targeted Cyber Intrusion How the 35 mitigations against targeted cyber intrusion published by Defence Signals Directorate can be implemented on the Microsoft technology
What is Really Needed to Secure the Internet of Things? By Alan Grau, Icon Labs email@example.com The Internet of Things (IoT) has become a ubiquitous term to describe the tens of billions of devices
Software Application Control and SDLC Albert J. Marcella, Jr., Ph.D., CISA, CISM 1 The most effective way to achieve secure software is for its development life cycle processes to rigorously conform to
FREQUENTLY ASKED QUESTIONS Continuous Monitoring 1. What is continuous monitoring? Continuous monitoring is one of six steps in the Risk Management Framework (RMF) described in NIST Special Publication
Entire contents 2011 Praetorian. All rights reserved. Information Security Provider and Research Center www.praetorian.com Threat Modeling "Threat modeling at the design phase is really the only way to
Threat Modeling Categorizing the nature and severity of system vulnerabilities John B. Dickson, CISSP What is Threat Modeling? Structured approach to identifying, quantifying, and addressing threats. Threat
ANALYSIS OF SOFTWARE THREATS AND SOFTWARE SECURITY Dr. Deepshikha Jamwal Bhawana Sharma Research Scholar Research scholar firstname.lastname@example.org email@example.com Department of Computer Science
Seven Practical Steps to Delivering More Secure Software January 2011 Table of Contents Actions You Can Take Today 3 Delivering More Secure Code: The Seven Steps 4 Step 1: Quick Evaluation and Plan 5 Step
2/1/2012 Assessor: J. Doe Disclaimer This report is provided as is for informational purposes only. The Department of Homeland Security (DHS) does not provide any warranties of any kind regarding any information
AIRDEFENSE SOLUTIONS PROTECT YOUR WIRELESS NETWORK AND YOUR CRITICAL DATA SECURITY AND COMPLIANCE THE CHALLENGE: SECURE THE OPEN AIR Wirelesss communication lets you take your business wherever your customers,
KASPERSKY SECURITY INTELLIGENCE SERVICES. EXPERT SERVICES www.kaspersky.com EXPERT SERVICES Expert Services from Kaspersky Lab are exactly that the services of our in-house experts, many of them global
Developing Secure Software in the Age of Advanced Persistent Threats ERIC BAIZE EMC Corporation DAVE MARTIN EMC Corporation Session ID: ASEC-201 Session Classification: Intermediate Our Job: Keep our Employer
Data Sheet Cisco Advanced Services for Network Security IP Communications networking the convergence of data, voice, and video onto a single network offers opportunities for reducing communication costs
REGULATIONS FOR THE SECURITY OF INTERNET BANKING PAYMENT SYSTEMS DEPARTMENT STATE BANK OF PAKISTAN Table of Contents PREFACE... 3 DEFINITIONS... 4 1. SCOPE OF THE REGULATIONS... 6 2. INTERNET BANKING SECURITY
Information Technology Security Review April 16, 2012 The Office of the City Auditor conducted this project in accordance with the International Standards for the Professional Practice of Internal Auditing
SECURITY RISK MANAGEMENT ISACA Atlanta Chapter, Geek Week August 20, 2013 Scott Ritchie, Manager, HA&W Information Assurance Services Scott Ritchie CISSP, CISA, PCI QSA, ISO 27001 Auditor Manager, HA&W
Application Security in the Software Development Lifecycle Issues, Challenges and Solutions www.quotium.com 1/15 Table of Contents EXECUTIVE SUMMARY... 3 INTRODUCTION... 4 IMPACT OF SECURITY BREACHES TO
Ohio Supercomputer Center IT Business Continuity Planning No: Effective: OSC-13 06/02/2009 Issued By: Kevin Wohlever Director of Supercomputer Operations Published By: Ohio Supercomputer Center Original
Department of Information Technology Remote Access Audit Final Report January 2010 promoting efficient & effective local government Background Remote access is a service provided by the county to the Fairfax
Cyber Security Risk Management: A New and Holistic Approach Understanding and Applying NIST SP 800-39 WebEx Hosted by: Business of Security and Federal InfoSec Forum April 12, 2011 Dr. Ron Ross Computer
AIRDEFENSE SOLUTIONS PROTECT YOUR WIRELESS NETWORK AND YOUR CRITICAL DATA SECURITY AND COMPLIANCE THE CHALLENGE: SECURE THE OPEN AIR Wirelesss communication lets you take your business wherever your customers,
Web application security Executive brief Managing a growing threat: an executive s guide to Web application security. Danny Allan, strategic research analyst, IBM Software Group Contents 2 Introduction
CYBER SECURITY AND RISK MANAGEMENT An Executive level responsibility Cyberspace poses risks as well as opportunities Cyber security risks are a constantly evolving threat to an organisation s ability to
The Software Supply Chain Integrity Framework Defining Risks and Responsibilities for Securing Software in the Global Supply Chain July 21, 2009 Editor Stacy Simpson, SAFECode Contributors Dan Reddy, EMC
KirkpatrickPrice Assessment Guide Designed Exclusively for PRISM International Members KirkpatrickPrice. innovation. integrity. delivered. KirkpatrickPrice Assessment Guide 2 Document Purpose The Assessment
Number 5.0 Policy Owner Information Security and Technology Policy Application Development Effective 01/01/2014 Last Revision 12/30/2013 Department of Innovation and Technology 5. Application Development
Cloud Computing Technologies Achieving Greater Trustworthiness and Resilience Cloud Standards Customer Council Public Sector Cloud Summit March 24, 2014 Dr. Ron Ross Computer Security Division Information
Framework for building a vulnerability management lifecycle program http://searchsecurity.techtarget.com/magazinecontent/framework-for-building-avulnerability-management-lifecycle-program August 2011 By
Unified Security Reduce the Cost of Compliance Introduction In an effort to achieve a consistent and reliable security program, many organizations have adopted the standard as a key compliance strategy
Cisco IT Best Practice Collaboration Security Cisco on Cisco Best Practice Security Practices for Online Collaboration and Social Media January 2012 2013 Cisco and/or its affiliates. All rights reserved.
University of Illinois at Urbana-Champaign BADM 557 Enterprise IT Governance Guide to Vulnerability Management for Small Companies Andrew Tan Table of Contents Table of Contents... 1 Abstract... 2 1. Introduction...
January 2012 Cisco on Cisco Best Practice Security Practices for Online Collaboration and Social Media January 2012 All contents are Copyright 1992 2012 Cisco Systems, Inc. All rights reserved. This document
ISO 27002 Compliance Guide September 2015 Contents Compliance Guide 01 02 03 Introduction 1 Detailed Controls Mapping 2 About Rapid7 7 01 INTRODUCTION If you re looking for a comprehensive, global framework
Cybersecurity Kill Chain William F. Crowe, CISA, CISM, CRISC, CRMA September 2015 ISACA Jacksonville Chapter Meeting August 13, 2015 Who Am I? Over 20 years experience with 17 years in the financial industry
Information Technology Engineers Examination Information Security Specialist Examination (Level 4) Syllabus Details of Knowledge and Skills Required for the Information Technology Engineers Examination
DATABASE SECURITY MECHANISMS AND IMPLEMENTATIONS Manying Qiu, Virginia State University, firstname.lastname@example.org Steve Davis, Clemson University, email@example.com ABSTRACT People considering improvements in database
Corporate Security Research and Assurance Services We Keep Your Business In Business Obrela Security Industries mission is to provide Enterprise Information Security Intelligence and Risk Management Services
Security and Vulnerability Testing How critical it is? It begins and ends with your willingness and drive to change the way you perform testing today Security and Vulnerability Testing - Challenges and
How to start a software security initiative within your organization: a maturity based and metrics driven approach Marco Morana OWASP Lead/ TISO Citigroup OWASP Application Security For E-Government Copyright
Managing internet security GOOD PRACTICE GUIDE Contents About internet security 2 What are the key components of an internet system? 3 Assessing internet security 4 Internet security check list 5 Further
Purpose: The Department of Information Technology (DoIT) is committed to developing secure applications. DoIT s System Development Methodology (SDM) and Application Development requirements ensure that
defending against advanced persistent threats: strategies for a new era of attacks agility made possible security threats as we know them are changing The traditional dangers IT security teams have been
MEDICAL DEVICE Cybersecurity. 2 MEDICAL DEVICE CYBERSECURITY Introduction Wireless technology and the software in medical devices have greatly increased healthcare providers abilities to efficiently and
Board Portal Security: How to keep one step ahead in an ever-evolving game The views and opinions expressed in this paper are those of the author and do not necessarily reflect the official policy or position
QUANTITATIVE MODEL FOR INFORMATION SECURITY RISK MANAGEMENT Rok Bojanc ZZI d.o.o. firstname.lastname@example.org Abstract: The paper presents a mathematical model to improve our knowledge of information security and
CENTER FOR ADVANCED SECURITY TRAINING 619 Advanced SQLi Attacks and Countermeasures Make The Difference About Center of Advanced Security Training () The rapidly evolving information security landscape
IS TEST 3 - TIPS FOUR (4) levels of detective controls offered by intrusion detection system (IDS) methodologies. First layer is typically responsible for monitoring the network and network devices. NIDS
External Supplier Control Requirements Cyber Security For Suppliers Categorised as High Cyber Risk Cyber Security Requirement Description Why this is important 1. Asset Protection and System Configuration
Cisco Security Optimization Service Proactively strengthen your network to better respond to evolving security threats and planned and unplanned events. Service Overview Optimize Your Network for Borderless
National Identity Exchange Federation (NIEF) Trustmark Signing Certificate Policy Version 1.1 February 2, 2016 Copyright 2016, Georgia Tech Research Institute Table of Contents TABLE OF CONTENTS I 1 INTRODUCTION
Cyber Essentials Scheme Requirements for basic technical protection from cyber attacks June 2014 December 2013 Contents Contents... 2 Introduction... 3 Who should use this document?... 3 What can these
It is a well-known fact in computer security that security problems are very often a direct result of software bugs. That leads security researches to pay lots of attention to software engineering. The
End Point Security How to Secure Your Environment Learning Objectives Define Endpoint Security Describe most common endpoints of data leakage Identify most common security gaps Preview solutions to bridge
Developing the Corporate Security Architecture www.avient.ca Alex Woda July 22, 2009 Avient Solutions Group Avient Solutions Group is based in Markham and is a professional services firm specializing in
Information Security Standards Web Application Development Standard IS-WAD Effective Date TBD Email email@example.com # Version 2.0 Contact Mike Cook Phone 408-924-1705 Standard: Web Application Development
Managing Vulnerabilities for PCI Compliance White Paper Christopher S. Harper Managing Director, Agio Security Services PCI STRATEGY Settling on a PCI vulnerability management strategy is sometimes a difficult
Security Standards Symantec shall maintain administrative, technical, and physical safeguards for the Symantec Network designed to (i) protect the security and integrity of the Symantec Network, and (ii)
Advanced Endpoint Protection Overview Advanced Endpoint Protection is a solution that prevents Advanced Persistent Threats (APTs) and Zero-Day attacks and enables protection of your endpoints by blocking
CIP- 005 R2: Understanding the Security Requirements for Secure Remote Access to the Bulk Energy System Purpose CIP-005-5 R2 is focused on ensuring that the security of the Bulk Energy System is not compromised
DIVISION OF INFORMATION SECURITY (DIS) Information Security Policy Information Systems Acquisitions, Development, and Maintenance v1.0 October 15, 2013 Revision History Update this table every time a new
SAFECode Security Development Lifecycle (SDL) Michael Howard Microsoft Matthew Coles EMC 15th Semi-annual Software Assurance Forum, September 12-16, 2011 Agenda Introduction to SAFECode Security Training
The Electronic Arms Race of Cyber Security 4.2 Lecture 7 ISIMA Clermont-Ferrand / 04-February 2011 Copyright 2011 Dr. Juergen Hirte List of Content Why Process Automation Security? Security Awareness Issues
External Supplier Control s Cyber Security For Suppliers Categorised as Low Cyber Risk 1. Asset Protection and System Configuration Barclays Data and the assets or systems storing or processing it must
Health IT Standards Committee Meeting Security Risk Management For Health IT Systems and Networks NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY 1 Setting the stage. NATIONAL INSTITUTE OF STANDARDS AND
White Paper Smart Grid Security: Preparing for the Standards-Based Future without Neglecting the Needs of Today Are you prepared for future data and infrastructure security challenges? Steve Chasko Principal
Privacy + Security + Integrity Docufree Corporation Data Security Checklist Security by Design Docufree is very proud of our security record and our staff works diligently to maintain the greatest levels
How to Protect Your Business from Malware, Phishing, and Cybercrime The SMB Security Series Streamlining Web and Email Security sponsored by Introduction to Realtime Publishers by Don Jones, Series Editor
APPENDIX A Appendix A Learning Continuum A-1 Appendix A Learning Continuum A-2 APPENDIX A LEARNING CONTINUUM E D U C A T I O N Information Technology Security Specialists and Professionals Education and
Threat Modeling Frank Piessens (Frank.Piessens@cs.kuleuven.be ) Secappdev 2007 1 Overview Introduction Key Concepts Threats, Vulnerabilities, Countermeasures Example Microsoft s Threat Modeling Process
Development*Process*for*Secure* So2ware Development Processes (Lecture outline) Emphasis on building secure software as opposed to building security software Major methodologies Microsoft's Security Development
Report to the Public Accounts Committee on mitigation of cyber attacks October 2013 REPORT ON MITIGATION OF CYBER ATTACKS Table of contents I. Introduction and conclusion... 1 II. How government bodies
Detecting Web Application Vulnerabilities Using Open Source Means OWASP 3rd Free / Libre / Open Source Software (FLOSS) Conference 27/5/2008 Kostas Papapanagiotou Committee Member OWASP Greek Chapter firstname.lastname@example.org
Recommended Practice Case Study: Cross-Site Scripting February 2007 iii ACKNOWLEDGEMENT This document was developed for the U.S. Department of Homeland Security to provide guidance for control system cyber
Is Drupal secure? A high-level perspective on web vulnerabilities, Drupal s solutions, and how to maintain site security Presented 2009-05-29 by David Strauss Thinking Securely Security is a process, not
- Table of Contents - 1 INTRODUCTION... 1 1.1 TARGET READERS OF THIS DOCUMENT... 1 1.2 ORGANIZATION OF THIS DOCUMENT... 2 1.3 COMMON CRITERIA STANDARDS DOCUMENTS... 3 1.4 TERMS AND DEFINITIONS... 4 2 OVERVIEW
Risk Management Guide for Information Technology Systems NIST SP800-30 Overview 1 Risk Management Process that allows IT managers to balance operational and economic costs of protective measures and achieve
Payment Card Industry (PCI) Terminal Software Security Best Version 1.0 December 2014 Document Changes Date Version Description June 2014 Draft Initial July 23, 2014 Core Redesign for core and other August
White Paper THE FOUR ATTACK VECTORS TO PREVENT OR DETECT RETAILER BREACHES By James Christiansen, VP, Information Risk Management Executive Summary Security breaches in the retail sector are becoming more
IBM Global Technology Services Leveraging innovative security solutions for government. Helping to protect government IT infrastructure, meet compliance demands and reduce costs Achieving a secure government
EVOLUTION OF CYBERSECURITY Click to edit Master title style IDENTIFYING BEST PRACTICES PHILIP DIEKHOFF, IT RISK SERVICES TECHNOLOGY THE DARK SIDE AGENDA Defining cybersecurity Assessing your cybersecurity