text:
|Publication number
|Publication type
|Application number
|Publication date
|Jan 3, 2012
|Filing date
|Sep 25, 2007
|Priority date
|Sep 25, 2007
|Fee status
|Also published as
|Publication number
|Talhah Munawar Mir, Anil Kumar Venkata Revuru, Deepak J. Manohar, Vineet Batta
|Original Assignee
|Microsoft Corporation
|Export Citation
|BiBTeX, EndNote, RefMan
|Patent Citations (32), Non-Patent Citations (12), Referenced by (69), Classifications (7), Legal Events (3)
|External Links: USPTO, USPTO Assignment, Espacenet
The use of computer-based networks (e.g., Internet based networks), provides information readily available to many users. Such networks can host multiple applications; however, the applications may be subject to security related attacks. Security related attacks have led to increased security measures to protect the information stored in or displayed on these applications. Protected information can include customer's banking information, social security numbers, email passwords, financial reports of organizations, etc.
Typically, the security aspect of an application comes after the software development lifecycle and is not an inherent part of the software development cycle itself. For such network based applications, security aspects are generally implemented at a later stage. This may result in an inadequate capability to handle various other security threats.
Security of such applications can be implemented by envisioning a threat model that simulates the threat that an application may be subjected to; however, existing threat models art typically realized for single applications and not the entire collection of applications (e.g., programs in a business enterprise). The typical threat management process is a manual process, which involves understanding and maintaining application security on par with the enterprise level security.
This summary is provided to introduce concepts relating to enterprise threat analysis and modeling for applications. These concepts are further described below in the detailed description. The presented summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.
In an embodiment, attributes, objectives, and functionality of a software application are identified. The software application is designed and code written for the software application based on a threat model that accounts for the attributes, objectives, and functionality.
The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.
Typically, applications are developed without taking into consideration various threats that the application may be subjected to. This arises due to inadequate or incomplete identification of the various threats that the application may face. Threats to an application are identified in order to classify the threats and further secure the application against these threats.
Threats to an application can include conditions that result in an unpredictable behavior of the application. Such threats can be software attacks, such as attacks through a malicious code. Threats can also include physical/mechanical failures like fires, water damage, and mechanical breakdowns. Threat analysis and modeling can be employed to describe a given threat and predict the harm it could inflict upon a vulnerable application. In addition, threat analysis and modeling can be employed to provide countermeasures against predicted attacks, and detailed methods to implement the countermeasures to remove the vulnerabilities of the applications.
Threat analysis and modeling can include defining a cost effective risk mitigation policy for a specific architecture, functionality, and configuration. Threat analysis and modeling can also involve mapping of assets, modeling of threats and building of a mitigation plan that lowers system risk to an acceptable level. The mitigation plan can include one or more countermeasures that can be effective against the identified threats.
Typically, threat analysis and modeling involves identifying one or more threats. Generally, each of the threats is mapped on to the attributes associated with elements of an application. The threats and the attributes associated with the elements of the application can be stored and various conditions can be identified as threats based on these attributes. For example, in an application that deals with data elements that include personally identifiable data (PII), PII could be one of the application's attributes and the possible threats to this kind of data could be confidentiality and integrity threats.
To this end, a system implements threat analysis and modeling by realizing a logical structure associated with an application. The logical structure can include elements such as components, roles, external dependencies, data, and so on. These elements can be extracted from the logical structure of the application. The elements of an application form the basis for threat analysis and modeling. The process by which the one or more elements can be extracted can interchangeably be referred to as application decomposition.
During application decomposition, the application can be broken down into the one or more elements, such as components, roles, external dependencies and data that make up basic building blocks of the application. The components of an application are the basic entities of an application and can include, for example, websites, processing servers, administrator client and so on. The role elements can include, for example "administrator", "particular users", "all users", etc.
External dependencies can be other applications linked to a particular application over which, the particular application has no control. Therefore, functionalities of the other applications can be implemented through these external dependencies. However, some dependencies may result in the execution of an improper code, which may threaten the integrity, or the normal functioning of the particular application. Data elements include the type of data handled by the application. For example, the data elements can include credit card data, user profile, social security number data and so on.
Once an application has been decomposed and the elements of the application have been identified, various attributes corresponding to each identified element are defined. The attributes describe characteristics of the elements, such as how the elements can be accessed, how the elements interact with each other, etc. One or more of the possible threats to a given application are identified based on the defined attributes of the elements. In one implementation, the threats can be identified based on previously experienced or monitored threat conditions. The identified threats are then analyzed and attacks that can be used to realize these threats are identified. For example, a high profile web server application can identify a non-availability threat, and the attack that can be used to realize this type of threat can be a distributed denial of service attack (DDoS). One or more of the attacks can be identified from a collection of possible attacks stored in a common task list.
The common task list includes extensible, customizable collections of previously known attacks that can be contextualized to the application. The CTL describes relationships between attacks, the vulnerability of the application to the attacks, and countermeasures for the vulnerability. The CTL also includes a control library. The control library contains one or more controls that ensure regulation, policies, and standards of an organization are implemented in the application development.
The identified attacks can be classified to prioritize and quantify the associated risks and effective countermeasures can be proposed in a threat model. In an implementation, various visualizations can be generated for enabling an individual (e.g., software author or developer), to implement threat analysis and modeling. Such visualizations, or action items, can present the threat model, including various reports or information, such as analytics, graphics, and visualization that give systematic instructions to implement the proposed actions (e.g., countermeasures).
Threat analysis and modeling may thus be implemented to provide a threat model having extensible and easily manageable information related to an application. Threat analysis and modeling along with associated risk management can be integrated within a typical software development life cycle or SDLC. Incorporation of the security policies into the SDLC improves operational efficiency.
Described here is a threat analysis and modeling technique that also analyzes and compares across an aggregate of threat models within an enterprise for customized reporting.
Exemplary Architecture for Threat Analysis and Modeling
The architecture 100 can include any number of the TAM client computing devices 110. For example, the system 100 can be the World Wide Web, including numerous PCs, servers, and other computing devices spread throughout the world. Alternatively, in another possible implementation, the system 100 can include a LAN/WAN with a limited number of PCs.
The TAM database 106, TAM web server 104 and the TAM client computing devices 110 can communicate with each other through the network 108 using one or more protocols, such as a transmission control protocol running over an internet protocol (TCP/IP). The TAM client computing devices 110 can be coupled to each other or to the TAM repository 102 in various combinations through a wired and/or wireless network, including a LAN, WAN, or any other networking technology known in the art.
The TAM web server 104 is capable of functioning as an interface for the TAM client 108 and the TAM ECP 112. The TAM repository 102 can also expose an application plug-in module interface allowing interfacing with external applications.
The TAM client computing devices (TAM clients) 110 interact with the TAM web server 104 for realizing one or more threat models that speculate as to the various threats to an application. The TAM web server 104 analyzes the threat models that can be defined by one or more of the TAM client 110 or can be pre-specified as a part of a default threat definition.
Users of the TAM clients 110 can identify the application for which a threat model has to be realized. Once the application has been identified, the TAM clients 110 perform application decomposition. During application decomposition, the TAM clients 110 request the users to identify the logical structure of the application and gather one or more of the application's elements that contribute to the logical structure. The logical structure can include elements such as component, roles, data, and application.
The TAM client 110 can then generate the threat model based on the gathered information. In one implementation, the TAM client 110 can download the CTL and the analysis rules at load time or when the TAM client 110 first interacts with the TAM web server 104. The TAM client 110 also receives management information and administrative functions from the TAM ECP 112. The TAM client 110 can then analyze and model the application to generate countermeasures against the vulnerabilities of the application.
In another implementation, the gathered information associated with one or more of the applications are communicated to the TAM web server 104, where it is analyzed based on the CTL stored in the TAM repository 102 along with management information and administrative functions from the TAM ECP 112. The TAM web server 104 provides one or more countermeasures to fix the vulnerabilities in the application.
In an implementation, the TAM ECP 112 can be a web site that can manage the entire threat analysis system including authorization model and other administration functions. Data analysis functionality including reporting and threat model queries along with threat model workflow can also be managed through the TAM ECP 112.
For generating the threat model, the TAM client 110 can implement a threat-analyzing module 114. The threat-analyzing module 114 can realize the threat model for an application and generate visual content, in the form of reports and charts. Such information may provide measures to protect the application against attacks. The threat-analyzing module 114 can receive input data from users on the TAM client 110, and generates an application task list or ATL that includes countermeasures to protect the application from known attacks. The ATL is generated from the CTL. The ATL includes a list of vulnerabilities, attacks, and countermeasures pertaining to a particular application. The ATL can be different for different applications. The ATL may depend on the attributes of the application.
The threat-analyzing module 114 requests the user to input one or more parameters that relate to an application for which the threat model is to be realized. Examples of such parameters include, but are not limited to application structure, objectives associated with the application, functionality, and so on. Based on this user information, the threat-analyzing module 114 generates a threat model that can deploy and centrally manage custom attributes for threat model elements with extensible values. The extensible values may be used to classify threat models.
In another implementation, the threat-analyzing module 114 can also implement suitable corrective actions to counter the identified vulnerabilities based on a set of rules associated with the application, which can enforce the user to implement the recommended countermeasures.
The threat-analyzing module 114 can allow organizations to deploy and centrally manage the CTL, which can be transformed into an attack library for backwards compatibility. The CTL can also help manage the relationship between common SDLC control task lists and policy, standards, and regulations of the enterprise.
Governing security groups can capture and deploy rules to automatically map the requirements of policy, standards, and regulations to contextualized applications through information collected in the threat models. With an integrated workflow, the threat model information can be directly tied to the activities of an application risk management process for improved operational efficiency.
An Exemplary System
The processor(s) 202 can be a single processing unit or a number of units, all of which could include multiple computing units. The processor(s) 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) 202 can be configured to fetch, and execute computer-readable instructions stored in the memory 208.
The network interface(s) 204 facilitates communication between the devices across a network, say network 108. Furthermore, the network interface(s) 204 may include one or more ports for connecting a number of computing devices to the each other or to a server-computing device. The network interface(s) 204 can facilitate communications within a wide variety of networks and protocol types, including wired networks (e.g., LAN, cable, etc.) and wireless networks (e.g., WLAN, cellular, satellite, etc.).
I/O interfaces 206 provide input-output capabilities for the TAM client 110. The I/O interfaces 206 can include one or more ports for connecting a number of input devices such as keyboard, mouse and so on and a number of the output devices such as monitor, speakers, and so on. In one implementation, the TAM client 110 receives input data from a user such as application component description via the keyboard or mouse connected through I/O interfaces 206.
The memory 208 can include any computer-readable medium known in the art including, for example, volatile memory (e.g., RAM) and/or non-volatile memory (e.g., flash, etc.). The memory 208 stores program instructions that can be executed by the processor(s) 202.
The memory 208 includes program modules 210 and program data 212. Program modules 210 include for example, the threat-analyzing module 114 and other module(s) 214. The program data 212 includes threat analysis data 216 and other data 218. The other data 218 stores data that may be generated or required during the functioning of the TAM client 110.
The threat-analyzing module 114 allows a developer to design security and risk management into an application by defining the application and its components, identifying risks and possible attacks, and providing countermeasures to prevent all the possible attacks on the application.
The threat-analyzing module 114 can accept various parametric values from the user via the input/output interfaces 206. The parametric values define one or more elements of the application under construction that can be associated with various threat models. The elements of an application can be associated with attributes. The attributes can include application attributes, role attributes, component attributes, and data attributes. The user can define these elements and their associated attributes through one or more parametric values in relation to the application, for which the threat analysis model is to be implemented. Therefore, a combination of parametric values can be indicative of a specific kind of threat.
The application attributes for the application can include information regarding the platform the application will be available on, whether the application can be internal facing or external facing, etc. The component attributes can include information regarding the type of apparatus in the application, the technology used, etc. For example, in a web application, the components can be website, order processing components, reports component, main database, log database, etc.
The user can also define the data attributes of the application. For example, the data can be Personally Identifiable Information (PII) such as social security numbers, and so on or the data can be high impact information such as the confidential financial details of an enterprise.
Furthermore, one or more of the role attributes of the applications can be defined. The roles assigned can be further broken down based on trust levels associated with the application. Examples of the roles in the application can include, but are not limited to administrators, support users, managers, employees, etc. A user can also define an authentication or an authorization process for each of the roles defined for the application. The information collected from a user regarding the application can be stored in the threat analysis data 216.
The threat-analyzing module 114 can utilize the attribute information provided by a user for the elements of the application for aggregate analysis. Typically, in enterprises, different organizational departments can have their own application management systems. The aggregate analysis can be performed on all the departmental applications to determine the security measures to be adopted, the level of security maintained for each department, drawbacks of certain proposed countermeasures if any, and so on. In this manner, the enterprise can assess risk across a number of applications. For example, if security personnel of an enterprise desire to analyze applications that handle PII, are externally facing, and are web applications; the threat-analyzing module 114 can provide a list of all the applications that adhere to the attribute information provided by the user, and perform an aggregate analysis for individual threat models simultaneously.
The threat-analyzing module 114 can request the user to supply information to generate an ATL. The threat-analyzing module 114 can generate the ATL based on the information provided by the user and the CTL stored in the TAM database 106 or downloaded onto the TAM client 110.
The ATL can include countermeasures for defending an application and one or more set of control rules enabling the application to become compliant with industry or technical standards, policies, and/or regulations set by the enterprise or regulation bodies. The ATL can be different for different applications, since the ATL depends on the attributes of the application.
The ATL may be an expandable list that can include one or more standards defined by an individual, such as a system administrator. For example, if an enterprise has a Line of Business (LOB) application standard, then the task items in the CTL could include input validation, exception handling, and so on. The structure of the CTL is further discussed below, in reference with
The CTL is a knowledge base containing possible guidelines against known attacks, and may be stored in the TAM database 106 or downloaded onto the TAM client 110 initially. The ATL for an application is derived from the CTL. The threat-analyzing module 114 based on the ATL, can advise a user how to implement a particular task item or countermeasure. Furthermore, the threat-analyzing module 114 can advise the user in which circumstances to use a particular countermeasure and advise the user about the reasons for selecting a particular countermeasure for a particular possible attack.
The threat-analyzing module 114 can apply rules to the applications depending on the attributes defined by the user and stored in the threat analysis data 218. Depending on the attributes pertaining to the application, the threat model can set internal policies that enforce these rules on the application once the threat model is created by the threat-analyzing module 114.
For example, in a case where an application dealing with credit card information, the data attribute defined could be personally identifiable information (PII). Application developers, while developing the application, have to reduce the risk associated with the potential confidentiality compromise of the credit cards. Therefore, the threat model enforces a rule mandating data encryption requirements and so on. This can be automated, where one or more rules can automatically be implemented on the application. Rules are defined and described in detail below. Furthermore, the threat-analyzing module 114 can include a user interface that can present pictorial icons for display on the output device.
Common Task List Structure
Organizations typically follow a hierarchy that translates policies into actual tasks. These policies may be implemented by an organization's information technology (IT) department. The hierarchy generally followed may regulations, corporate policies, standards, and action items.
As an example, the regulations can be decided and set by external regulatory bodies. Examples of regulations can be Sarbanes-Oxley (SOX) Act, Payment Card Industry (PCI) regulation, Health Insurance Portability and Accountability Act (HIPAA), and so on. The regulations can then be translated into policies implemented by organizations. Examples of policies can be confidentiality and proprietary information policies, information security policies, and privacy policies. These policies may vary for different organizations based on organizational requirements. The policies may be translated into standards, within the organization. Examples of standards within an organization can include, information classification and handling standards, identity management standards, line of business application standards, and so on. Applications may be built to include action items that implement these standards. For example, the action items in applications may include input validation, exception handling, output encoding, and so on.
The standards and the action items may be such that the issues they tend to address are separated. The CTL combines both the standards and the action items. The action items are defined such that they are pertinent to the threat they are supposed to address or counter. Furthermore, such action items should comply with one or more defined standards.
The CTL 302 includes an attack library and a control library. The attack library can contain information pertaining to the technology attributes 308, their vulnerabilities, and the countermeasures to fix the vulnerabilities. For example, the attack task list of the CTL 302 can have the following structure.
<Applicability attributes> (extensible)
[design, code, infrastructure, operational]
{Code}→ [Input Val, Parameter Man, Session Mgmt]
{Infra} → [Patches, Files, Shares ...]
(obtained from Patterns & Guidance)
[ASP.NET, SQL Server 2005, Windows Vista, ...]
[IVM Matrix]
[Possible attack mitigated]
<control UID(s)>
In the above representation, applicability attributes can be represented as technology attributes namely role 310, data 312, application 314 and component 316. The type of application can also be defined, where the type of application field may include the design of the application, the code used, the infrastructure involved such as patches, files and shared files, and the operation of the application. Technology used may also be defined from a list of technologies available. In some cases, if the technology used does not exist in the model, the user can define the new technology. One or more fields may indicate possible attacks and countermeasures available to address or counter an identified threat. Instructions may give to implement the countermeasures; and verify and monitor the countermeasures.
The control library can include information pertaining to the standards, regulations, and policies of an enterprise. The control library can also define the parties involved in the application threat model and can determine the priority of task items. An exemplary structure for control library is as follows:
<applicability attributes> (extensible)
<data attributes>
<role attributes>
[Authentication, Authorization, Auditing, Logging, ...]
[Unique identifier - UID]
[Actual text entry]
[RAAI Matrix]
[Responsible] { } (doer/implementer}
[Accountable] { } (business/risk owner}
[Auditor] { } (security/auditor analyst)
[Informed] { } (Exec business owner)
[Control priority - selection]
[Policy section, Regulation section]
In the above example, the applicability attributes define the attributes of an application, i.e. role 310, application 312, data 314, and components 316. The category as it appears in the above control list, refers to the type of security that may be required and can include authentication, authorization, auditing, logging etc. The entry field is the details pertaining to attacks and countermeasures. The entry field can include the name of the threat or countermeasure, a unique identification number and a brief textual description regarding the attack or the countermeasure.
The control list library can provide information regarding the different people/users involved in the threat model. For example, the people involved can be individuals responsible for implementing the threat model, where the accountable person that can include an organization owner, an auditor, and an informed party (e.g., executive business owners).
The control list can also specify one or more priorities. The priorities can be either set by a user or automatically based on the threat model realized. These priorities can indicate the possible attacks that require immediate attention or are the most probable. In another implementation, the countermeasures can also be prioritized based on their relevance to the application attributes.
The task items 304 in
<ACE Area>
<Task-list Item Identifier>
[Design/Code/Infrastructure (config)/Operational]
<Title> (Should be less than 5 words)
<Description> (Should be less than 10 words)
Role - [Attribute Name] - [Attribute Value]
Data - [Attribute Name] - [Attribute Value]
Component - [Attribute Name] - [Attribute Value]
Application - [Attribute Name] - [Attribute Value]
<Where to Implement?>
<How to Implement?>
(URL and CWE mapping)
<Related Attack/Implication>
In the above illustration, the ACE Area indicates any one of the possible threat areas, such as security, privacy, performance, and so on. Any one of the areas can be selected that the task list item applies to. The task item identifier is a unique number called the unique task item ID that identifies the task item. Each task item may have its own unique task item ID. The category field allows the user to select a security category from a drop down list; any appropriate category can be selected from the list. For example, the categories can be authentication, authorization, auditing, logging on, and so on. If the category does not exist in a drop down box, the user can enter an appropriate category in the field. In certain cases, some categories can also have sub-category entries from which one or more options can be selected. In the above illustrated task item, other fields can be characterized that would define the various task items that are applicable to a given threat.
Rule Driven Threat Modeling Automation
As indicated, a threat model enables a system user to understand risks that an application may be vulnerable to, prior to the development stage of the application. The threat modeling assists in defining an acceptable assurance level. This acceptable assurance level is then translated into one or more key controls to be implemented for countering the perceived threat. The key controls can be the task items from the CTL. The application during development can be reviewed to ascertain whether the assurance level defined by the developer is acceptable at the enterprise level or not.
The threat model as described can also include one or more defined rules. For example, the threat model can support two types of rules, in particular, threat configuration rules and CTL binding rules. Each of the two rules can be broken up into two part namely, qualifiers and effects. Qualifiers define the applicability of the rule. Effects define the effect or a behavioral change a system may display on the application of the rules. The qualifier for both the threat configuration rules and CTL binding rules can be applied against the attributes, which for each threat, can be obtained by analyzing the attributes associated with each threat. The application attributes can be the same for each threat since they are related to the entire threat model.
It is noted that the threat configuration rule may be different for each threat type, i.e., confidentiality, integrity or availability threat. For different threat types, users can be given options to configure the rules. For example, a user can define a name and a related description for one or more threats. The user can also configure the risk impact field as high, medium or low. A risk probability field can also be configured to "high", "medium" or "low." Other risk related options and parameters can be defined that would be indicative of the risk posed by a threat and the nature of the response to be meted out in view of the perceived risk.
Common configurations for all threat categories can be accompanied by certain primary threat factors that vary for each security threat. For example, for a confidentiality threat in which confidential information related to an individual may be at risk of being disclosed to unauthorized individuals, the user can specify values for properties such as "unauthorized disclosure of the identity" and "unauthorized disclosure of the data" fields. An affirmative for these properties would disallow all unauthorized exposure of the confidential information to outside individuals. In this manner, other types of threats can be controlled or prevented by specifying values to one or more properties associated with these threats.
The CTL binding rule offers task items from the CTL if a qualifier is matched against an attribute of the application. The task item ID is applied to the qualified threat and the CTL task item corresponding to the task item ID can be imported from the CTL.
In another implementation, privacy requirements can be enforced to preserve the secrecy of information related to applications dealing with PII. In such cases, the PII collected from the users and the application has a CTL binding rule to enforce certain privacy policies on the application.
Integrated Threat Modeling Workflow
A feature of the disclosed threat analysis and modeling is an integrated threat modeling (TM) workflow. The threat modeling workflow may be performed during various stages of a typical software development life cycle. In a part that includes review cycle, implementation is at an application design stage. Another part may be aligned with an application test stage.
The first phase of the SDLC can be an envision phase 502. In the envision phase 502, the application can be identified, and the application's main objectives and functionality to be implemented can be discussed. The envision phase 502 may also include outlining one or more standards and policies for the application.
The SDLC 500 includes a design phase 504. In the design phase 504, the basic building blocks of the application can be identified. The threat modeling for the application can be done in this phase of the cycle. For example, the design phase 504 can include various aspects of application development such as defining attributes of the application, deciding the technology to be used, identifying the platform that would host the application and the level of security required for the application. The threat model can be analyzed based on the attributes, objectives, and functionality of the application. At the design phase 504, various threats can be identified. Upon identification of the threats one or more changes can be made to the envision phase 502 and the design phase 504 stage of the SDLC 500. The phases can be repeated until the number of threats is minimized to a desired level. This can be implemented at the TM review workflow 506 stage that is described later.
The SDLC 500 can include a development phase 508. In this phase, code implementing one or more functionalities identified in the envision phase 502 and design phase 504 is generated. Code development is performed keeping in mind various threats the application may be subjected to and incorporating within the code, instructions for countering the threats. The countermeasures can be implemented in accordance with the threat model generated in the design phase 504.
Once the application is developed, the application can undergo a test phase 510 phase. The application can be internally tested for various possible cases. The application is tested for its functionality and security. Possible attacks can be applied to the application to test the vulnerability of the application under attack. During the test phase 510, various speculated threats are ascertained. In some cases, some the application may be subjected to a new type of threat that had escaped (i.e., not identified) the threat modeling of the application.
After the internal testing has been completed, the software application reaches the final or release phase 512 of the SDLC 500. The released application can be constantly monitored to make sure it meets the desired security assurance level and operates in accordance to its functionality and objectives.
As indicated previously, TM review workflow 506 may be applied in parallel with the design phase 504. The TM review workflow 506 can be used to review and obtain a confirmation on the threat model. The TM review workflow 506 includes reviewing the application task list (ATL) that can be used for defining one or more task items that will be implemented as a part of the application development for managing the identified risks. An exemplary workflow method is described below with reference to
A threat modeling (TM) verification workflow 514 is used to verify the results of the comprehensive security assessment of the application against the threat model in the test phase 510. The threat modeling verification workflow 514 can be used to verify whether all the task items identified as part of the threat modeling process implemented correctly during the develop phase 508 of the application. If not, then a regression may have to be performed to outline various ATL task items to be implemented, to correctly ascertain various threats the application may be prone to.
Exemplary Method(s)
At block 602, a user of a TAM client 110 can define an application to be analyzed and modeled. The user can define the application and provide information associated with the application to be stored as threat analysis data 216. The information as collected in the threat analysis data 216 is indicative of the objectives and functionality of the application. In an implementation, the application design can be identified. Furthermore, a risk assessment can be carried out on the application to determine the desired assurance level required for the application depending on the type of data handled by the application, such as PII, and so on.
At block 604, the architecture of the application can be defined. At this stage, the design or the logical structure on which the application is based is determined. In one implementation, the user can determine the logical structure associated with the application. The structural blocks of the application include, but are not limited to website, web-service, and order-processing module and so on. The threat-analyzing module 114 can determine attributes and the rules relating to the application. The rules can be based on the attributes of the application, and other factors such as the technology used, the coding language to be used, the platform the application is going to be hosted on and so on.
At block 606, the threat model can be generated. In an embodiment, generation of the threat model includes generation of an ATL. The ATL can be generated by selecting task items from the CTL that pertain to the application being modeled. The CTL and related information can be stored in the TAM database 106 and the CTL can be downloaded at the TAM client device 110 from the TAM database 106. The threat-analyzing module 114 retrieves application related information from the threat analysis data 216 and the CTL for generating the ATL. The ATL pertains to the application whose threat model is being designed. The ATL includes task items to be implemented in the application for making the application secure against known probable attacks. The known probable attacks can be listed in accordance with attributes and rules of the application and countermeasures against the known attacks can be listed in the ATL's task items.
At block 608, the threat model generated at block 506 can be classified. For example, the threat-analyzing module 114 can set priorities for the task items that need to be implemented depending on the vulnerabilities of the application they are meant to fix. The user can select priorities from a list containing priority values high, medium and low. Once the threat model is generated and classified, the threat model can be used to develop the application and implement the task items stated in the threat model to create a secure application.
At block 702, a new threat model is initiated. The new threat model can be initiated automatically online on the TAM web server 104. In another implementation, the threat model can be initiated by the threat-analyzing module 114 at the TAM client device 110. An author or developer may initiate work on a new threat model for an application. The initiated threat model can be stored on an external storage medium that can be accessible through a wired or wireless network, such as the Internet. The threat model can be stored in the TAM repository 102.
At block 704, the saved threat model can be edited. The author or developer can choose to save the threat model on-line in the TAM repository 102, so that the other parties can access the threat model. As part of the modeling, the author can also have the ability to view the current application task list or ATL that shows one or more of the task items to be implemented as part of the application develop phase 508. With each task item, the author has the ability to select responses such as "implement", "file exception", and "not applicable."
The "implement" response selected by the author can indicate that the application team commits to incorporate the task item into the application and implement the task item during the develop phase 508 phase. The "file exception" response indicates an exception for the task item. The reason for choosing this option can vary anywhere from technical infeasibility to resource constraint. The "not applicable" response indicates that the current task item is not applicable in the context of the application. The threat model in the TAM repository 102 can also be set to an "In Edit" state.
At block 706, the threat model can be submitted for review. The author or developer can chose to have the threat model reviewed. In an implementation, the threat model can automatically be sent for review. At this stage, the threat model's state can be set to "Awaiting Review."
At block 708, a notification is sent to the appropriate reviewers indicating a review is required for a threat model. In one implementation, this review notification can be sent automatically by the threat-analyzing module 114 once the state of the threat model is set to "awaiting review". In another implementation, the author has to manually send a review notification mail to the reviewer.
At block 710, the threat model is retrieved and reviewed. The reviewers review the application task list ATL and the responses within the ATL for each task item. The reviewing can be performed based on information included in the ATL.
At block 712, after the threat model has been reviewed, a decision can be made whether or not the threat model can be considered complete. If the threat model is considered complete (i.e., following the YES path from block 712), at block 714, the threat model can be submitted. The threat-analyzing module 114 can send a notification to the authors stating no more action is required. Alternatively, if the threat model is not complete (i.e., following the NO path from block 712), at block 716 the reviewed threat model can be returned with feedback comments to the authors (developers). At block 716, any feedbacks or inputs received during the reviewing process forms a part of an edit notification.
At block 718, an edit notification email can be sent to the application team indicating that the threat model has been reviewed and that the reviewer has provided a feedback. The authors may take some actions and edit the threat model. The edit information acts as inputs for further editing of the saved threat models. Such information provides insights into the areas within the application where further security is required to counter related threats. The process 700 then repeats from block 704 until the threat model is considered complete and the reviewers sign off on the threat model.
At block 802, the verification of the threat model can be initiated. The threat model can be retrieved from the TAM repository 102. Once the application is developed at the develop phase 508, the application can undergo extensive tests, at this phase the threat model is verified to ensure the threat model has been successful in implementing the recommended countermeasures.
At block 804, the verification state of an application task list is inferred. Any unsuccessful implementation of the task items listed in an ATL can result in bugs being present in the application. The TAM repository 102 can execute an automated process to analyze the bugs against the application and infer their association with the task items in the ATL. For all mapped task items that have bugs, the verification status can be set to "failed". The process of verifying the correct implementation of identified task items can be derived by analyzing the bugs. Any suitable software known in the art that performs code failure analysis can be used to analyze the bugs. In another implementation, the verification can be done manually.
At block 806, the threat-analyzing module 114 can determine whether the threat model verification has passed. The determination is made based on the ATL. If at least one task item is marked as "failed", the threat model verification also fails. Conversely, in the absence of any "failed" task items, the threat verification passes.
If the threat model verification passes (i.e., following the YES path from block 806), at block 808 the threat model verification can be completed. Alternatively, if the threat model verification has not passed (i.e., following the NO path from block 806), at block 810 a regression process can be initiated for the application. The regression process can include repeating the design phase 504 for the application. The various factors that taken into consideration may be revisited to provide a better threat model that is better related to the application's functionality and desired objectives. In particular implementations, the regression process may begin from envision phase 502.
At block 808, the verification is complete, and the threat model document's state can be set to "closed." In an implementation, a passed verification notification can be sent to the members of an application team(s), notifying them that the threat model verification has been completed and no further action is needed. For example, an email notification can be automatically sent by the threat-analyzing module 114, once the threat models status is set to "closed" or the reviewer can manually send the email notification to the application team(s).
Exemplary Computing Environment
Computer environment 900 includes a general-purpose computing-based device in the form of a computer 902. Computer 902 can be, for example, a desktop computer, a handheld computer, a notebook or laptop computer, a server computer, a game console, and so on. The components of computer 902 can include, but are not limited to, one or more processors or processing units 904, a system memory 906, and a system bus 908 that couples various system components including the processor 904 to the system memory 906.
The system bus 908 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, such architectures can include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnects (PCI) bus also known as a Mezzanine bus.
Computer 902 typically includes a variety of computer readable media. Such media can be any available media that is accessible by computer 902 and includes both volatile and non-volatile media, removable and non-removable media.
The system memory 906 includes computer readable media in the form of volatile memory, such as random access memory (RAM) 910, and/or non-volatile memory, such as read only memory (ROM) 912. A basic input/output system (BIOS) 914, containing the basic routines that help to transfer information between elements within computer 902, such as during start-up, is stored in ROM 912 is illustrated. RAM 910 typically contains data and/or program modules that are immediately accessible to and/or presently operated on by the processing unit 904.
Computer 902 may also include other removable/non-removable, volatile/non-volatile computer storage media. By way of example,
The disk drives and their associated computer-readable media provide non-volatile storage of computer readable instructions, data structures, program modules, and other data for computer 902. Although the example illustrates a hard disk 916, a removable magnetic disk 920, and a removable optical disk 924, it is to be appreciated that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes or other magnetic storage devices, flash memory cards, CD-ROM, digital versatile disks (DVD) or other optical storage, random access memories (RAM), read only memories (ROM), electrically erasable programmable read-only memory (EEPROM), and the like, can also be utilized to implement the exemplary computing system and environment.
Any number of program modules can be stored on the hard disk 916, magnetic disk 920, optical disk 924, ROM 912, and/or RAM 910, including by way of example, an operating system 926, one or more application programs 928, other program modules 930, and program data 932. Each of such operating system 926, one or more application programs 928, other program modules 930, and program data 932 (or some combination thereof) may implement all or part of the resident components that support the distributed file system.
A user can enter commands and information into computer 902 via input devices such as a keyboard 934 and a pointing device 936 (e.g., a "mouse"). Other input devices 938 (not shown specifically) may include a microphone, joystick, game pad, satellite dish, serial port, scanner, and/or the like. These and other input devices are connected to the processing unit 904 via input/output interfaces 940 that are coupled to the system bus 908, but may be connected by other interface and bus structures, such as a parallel port, game port, or a universal serial bus (USB).
A monitor 942 or other type of display device can also be connected to the system bus 908 via an interface, such as a video adapter 944. In addition to the monitor 942, other output peripheral devices can include components such as speakers (not shown) and a printer 946, which can be connected to computer 902 via the input/output interfaces 940.
Computer 902 can operate in a networked environment using logical connections to one or more remote computers, such as a remote computing-based device 948. By way of example, the remote computing-based device 948 can be a personal computer, portable computer, a server, a router, a network computer, a peer device or other common network node, and the like. The remote computing-based device 948 is illustrated as a portable computer that can include many or all of the elements and features described herein relative to computer 902.
Logical connections between computer 902 and the remote computer 948 are depicted as a local area network (LAN) 950 and a general wide area network (WAN) 952. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.
When implemented in a LAN networking environment, the computer 902 is connected to a local network 950 via a network interface or adapter 954. When implemented in a WAN networking environment, the computer 902 typically includes a modem 956 or other means for establishing communications over the wide network 952. The modem 956, which can be internal or external to computer 902, can be connected to the system bus 908 via the input/output interfaces 940 or other appropriate mechanisms. It is to be appreciated that the illustrated network connections are exemplary and that other means of establishing communication link(s) between the computers 902 and 948 can be employed.
In a networked environment, such as that illustrated with computing environment 900, program modules depicted relative to the computer 902, or portions thereof, may be stored in a remote memory storage device. By way of example, remote application programs 958 reside on a memory device of remote computer 948. For purposes of illustration, application programs and other executable program components such as the operating system are illustrated herein as discrete blocks, although it is recognized that such programs and components reside at various times in different storage components of the computing-based device 902, and are executed by the data processor(s) of the computer.
Various modules and techniques may be described herein in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that performs particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.
An implementation of these modules and techniques may be stored on or transmitted across some form of computer readable media. Computer readable media can be any available media that can be accessed by a computer. By way of example, and not limitation, computer readable media may comprise "computer storage media" and "communications media."
"Computer storage media" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer.
Alternately, portions of the framework may be implemented in hardware or a combination of hardware, software, and/or firmware. For example, one or more application specific integrated circuits (ASICs) or programmable logic devices (PLDs) could be designed or programmed to implement one or more portions of the framework.
Although embodiments for implementing enterprise threat analysis and modeling have been described in language specific to structural features and/or methods, it is to be understood that the subject of the appended claims is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as exemplary implementations for the enterprise threat analysis and modeling.
|Cited Patent
|Filing date
|Publication date
|Oct 24, 1996
|Dec 14, 1999
|Inprise Corporation
|Development system with methods providing visual form inheritance
|Jun 6, 1997
|Jul 17, 2001
|Microsoft Corporation
|Run time object layout model with object type that differs from the derived object type in the class structure at design time and the ability to store the optimized run time object layout model
|Aug 31, 1999
|Dec 9, 2003
|Accenture Llp
|Managing information in an integrated development architecture framework
|Jul 16, 2001
|Nov 22, 2005
|Borland Software Corporation
|Frame component container
|May 17, 2001
|Jun 6, 2006
|Finjan Software, Ltd.
|Malicious mobile code runtime monitoring system and methods
|Sep 27, 2002
|Mar 13, 2007
|Manyeta Informatique Inc.
|System and method for managing architectural layers within a software model
|Mar 20, 2006
|Apr 24, 2007
|Infraegis, Inc.
|System and method for monitoring a security of an asset
|Feb 20, 2001
|May 1, 2007
|Hewlett-Packard Development Company, L.P.
|System and method for establishing security profiles of computers
|Aug 8, 2001
|Jul 10, 2007
|Microsoft Corporation
|Rapid application security threat analysis
|Jan 18, 2002
|Oct 16, 2007
|Cigital, Inc.
|System and method for identifying and eliminating vulnerabilities in computer software applications
|Oct 27, 2004
|Sep 9, 2008
|Arcsight, Inc.
|Dynamic security events and event channels in a network security system
|Dec 19, 2003
|Nov 11, 2008
|Rage Frameworks, Inc.
|System and method for developing user interfaces purely by modeling as meta data in software application
|Apr 19, 2001
|Mar 10, 2009
|Cybersoft, Inc.
|Software virus detection methods and apparatus
|May 4, 2004
|Mar 24, 2009
|Arcsight, Inc.
|Pattern discovery in a network security system
|Aug 25, 2005
|Aug 4, 2009
|Lockheed Martin Corporation
|System and method for reducing the vulnerability of a computer network to virus threats
|Jun 13, 2002
|Aug 25, 2009
|Intertrust Technologies Corporation
|Software self-checking systems and methods
|Dec 29, 2009
|International Business Machines Corporation
|Source code repair method for malicious code detection
|Oct 27, 2004
|Jan 5, 2010
|Arcsight, Inc.
|Security event aggregation at software agent
|Nov 8, 2004
|Jul 27, 2010
|Microsoft Corporation
|System and method of aggregating the knowledge base of antivirus software applications
|Nov 21, 2003
|Aug 31, 2010
|Citigroup Global Markets Inc.
|Method and system for data file processing
|Dec 24, 2003
|Sep 14, 2010
|Cloakware Corporation
|Secure method and system for biometric verification
|Feb 14, 2006
|Oct 19, 2010
|Microsoft Corporation
|Web application security frame
|Oct 11, 2002
|Oct 19, 2010
|The Trustees Of Columbia University In The City Of New York
|Methods for cost-sensitive modeling for intrusion detection and response
|May 24, 2011
|International Business Machines Corporation
|Development of information technology system
|Mar 7, 2002
|Jul 24, 2003
|Yoshihito Taninaka
|Security level information offering method and system
|Aug 26, 2003
|Mar 4, 2004
|Iven Connary
|Determining threat level associated with network activity
|Sep 12, 2003
|Aug 5, 2004
|Brandt David D.
|System and methodology providing automation security architecture in an industrial controller environment
|Nov 1, 2005
|May 11, 2006
|Scott Milener
|Method and apparatus for look-ahead security scanning
|Jan 11, 2005
|Jul 13, 2006
|International Business Machines Corporation
|Method of assuring enterprise security standards compliance
|Aug 2, 2005
|Jan 18, 2007
|Ygor Goldberg
|Practical threat analysis
|Nov 1, 2004
|May 17, 2007
|John Leach
|Method used in the control of a physical system affected by threats
|Dec 29, 2005
|Jul 5, 2007
|Microsoft Corporation
|Security modeling and the application life cycle
|Cock, et al., "Threat Modelling for Security Tokens in Web Applications", available at leaset as early as Jul. 26, 2007, at >, pp. 183-193.
|Cock, et al., "Threat Modelling for Security Tokens in Web Applications", available at leaset as early as Jul. 26, 2007, at <<http://sec.cs.kent.ac.uk/cms2004/Program/CMS2004final/p4a6.pdf>>, pp. 183-193.
|Futcher et al, "Guidelines for secure software development", ACM SAICIST, pp. 56-65, 2008.
|Gotterbarn, "Enchancing risk analysis using software development impact statements", IEEE, 43-51, 2001.
|Hui et al, "A bayesian belief network model and tool to evaluate risk and impact in software development projects", IEEE, pp. 297-301, 2004.
|Kocher et al, "Security as a new dimension in embedded system design", ACM DAC, pp. 753-760, 2004.
|Oladimeji, et al., "Security Threat Modeling and Analysis: A Goal-Oriented Approach", available at least as early as Jul. 26, 2007, at >, pp. 8.
|Oladimeji, et al., "Security Threat Modeling and Analysis: A Goal-Oriented Approach", available at least as early as Jul. 26, 2007, at <<http://www.utd.edu/˜eao015100/documents/SecurityThreatModeling.pdf>>, pp. 8.
|Pauli, et al., "Threat-Driven Architectural Design of Secure Information Systems", available at least as early as Jul. 26, 2007, at >, pp. 8.
|Pauli, et al., "Threat-Driven Architectural Design of Secure Information Systems", available at least as early as Jul. 26, 2007, at <<http://cs.ndsu.edu/˜dxu/publications/pauli-xu-ICEIS05.pdf>>, pp. 8.
|Smuts et al, "Critical success factors for information systems outsourcing management: a softwre development lifecycle view", ACM SAICSIT, pp. 304-313, 2010.
|Sultan et al, "Catalog of metrics for assessing security risks of software throughout the software development life cycle", IEEE, pp. 461-465, 2008.
|Citing Patent
|Filing date
|Publication date
|Nov 13, 2012
|Sap Ag
|Architectural design for intra-company stock transfer application software
|Nov 13, 2012
|Ygor Goldberg
|Practical threat analysis
|Nov 20, 2012
|Sap Ag
|Software model deployment units
|Dec 30, 2005
|Nov 27, 2012
|Sap Ag
|Architectural design for internal projects application software
|Mar 31, 2006
|Nov 27, 2012
|Sap Ag
|Composite application modeling
|Dec 4, 2012
|Sap Ag
|Providing supplier relationship management software application as enterprise services
|Dec 4, 2012
|Sap Ag
|Architectural design for product catalog management application software
|Sep 18, 2008
|Jan 8, 2013
|Sap Ag
|Architectural design for time recording application software
|Jan 22, 2013
|Sap Ag
|Computer readable medium for implementing supply chain control using service-oriented methodology
|Dec 30, 2005
|Feb 5, 2013
|Sap Ag
|Software model process component
|Feb 12, 2013
|Sap Ag
|Architectural design for opportunity management application software
|Sep 18, 2008
|Feb 19, 2013
|Sap Ag
|Architectural design for embedded support application software
|Dec 30, 2005
|Feb 19, 2013
|Sap Ag
|Architectural design for plan-driven procurement application software
|Feb 26, 2013
|Sap Ag
|Architectural design for plan-driven procurement application software
|Mar 12, 2013
|Sap Ag
|Architectural design for service procurement application software
|Mar 30, 2006
|Mar 12, 2013
|Sap Ag
|Providing customer relationship management application as enterprise services
|Mar 19, 2013
|Sap Ag
|Architectural design for make-to-specification application software
|Sep 18, 2008
|Mar 19, 2013
|Sap Ag
|Providing supplier relationship management software application as enterprise services
|Mar 19, 2013
|Sap Ag
|Architectural design for make to stock application software
|May 7, 2013
|Sap Ag
|Foundation layer for services based enterprise software architecture
|Mar 7, 2011
|May 7, 2013
|Isight Partners, Inc.
|Information system security based on threat vectors
|Mar 30, 2006
|May 14, 2013
|Sap Ag
|Providing accounting software application as enterprise services
|Dec 31, 2007
|May 21, 2013
|Sap Ag
|Architectural design for service procurement application software
|May 21, 2013
|Sap Ag
|Software model integration scenarios
|Jan 18, 2010
|Jul 23, 2013
|iSIGHT Partners Inc.
|Targeted security implementation through security loss forecasting
|Dec 30, 2005
|Aug 27, 2013
|Sap Ag
|Software modeling
|Mar 30, 2006
|Sep 17, 2013
|Sap Ag
|Providing payment software application as enterprise services
|Feb 22, 2011
|Nov 19, 2013
|Intuit Inc.
|Automatic provisioning of resources to software offerings
|Sep 18, 2008
|Nov 26, 2013
|Sap Ag
|Architectural design for service request and order management application software
|Jul 31, 2009
|Dec 10, 2013
|Citigroup Global Markets Inc.
|Method and system for data file processing
|Dec 11, 2008
|Mar 11, 2014
|Sap Ag
|Providing payroll software application as enterprise services
|Dec 30, 2005
|Mar 18, 2014
|Sap Ag
|Architectural design for self-service procurement application software
|Dec 3, 2008
|May 27, 2014
|Sap Ag
|Architectural design for selling standardized services application software
|Jun 3, 2008
|Aug 19, 2014
|Isight Partners, Inc.
|Electronic crime detection and tracking
|Sep 18, 2008
|Aug 26, 2014
|Sap Ag
|Architectural design for customer returns handling application software
|Jan 15, 2013
|Sep 30, 2014
|Taasera, Inc.
|Runtime risk detection based on user, application, and system action sequence correlation
|May 29, 2009
|Oct 7, 2014
|Verizon Patent And Licensing Inc.
|Device classification system
|Apr 12, 2013
|Apr 21, 2015
|Isight Partners, Inc.
|Information system security based on threat vectors
|Aug 2, 2005
|Jan 18, 2007
|Ygor Goldberg
|Practical threat analysis
|Dec 30, 2005
|Jul 5, 2007
|Stefan Kaetker
|Software model deployment units
|Dec 30, 2005
|Jul 5, 2007
|Arthur Berger
|Architectural design for plan-driven procurement application software
|Dec 30, 2005
|Jul 5, 2007
|Arthur Berger
|Architectural design for service procurement application software
|Dec 30, 2005
|Jul 5, 2007
|Volker Faisst
|Architectural design for internal projects application software
|Dec 30, 2005
|Jul 5, 2007
|Arthur Berger
|Architectural design for self-service procurement application software
|Dec 30, 2005
|Jul 5, 2007
|Markus Peter
|Architectural design for product catalog management application software
|Dec 30, 2005
|Jul 26, 2007
|Stefan Kaetker
|Software model integration scenarios
|Mar 30, 2006
|Oct 4, 2007
|Martin Schorr
|Providing accounting software application as enterprise services
|Mar 30, 2006
|Oct 4, 2007
|Alexander Koegler
|Providing customer relationship management application as enterprise services
|Mar 30, 2006
|Oct 4, 2007
|Martin Von Der Emde
|Providing payment software application as enterprise services
|Mar 30, 2006
|Oct 4, 2007
|Joachim Puteick
|Foundation layer for services based enterprise software architecture
|Mar 31, 2006
|Oct 4, 2007
|Uta Prigge
|Composite application modeling
|Dec 31, 2007
|Jul 2, 2009
|Christoph Jungkind
|Architectural Design for Service Procurement Application Software
|Jul 31, 2009
|Dec 3, 2009
|Hoberman Gary A
|Method and system for data file processing
|Dec 3, 2009
|Isight Partners, Inc.
|Electronic Crime Detection and Tracking
|Mar 18, 2010
|Sap Ag
|Architectural Design for Embedded Support Application Software
|Sep 18, 2008
|Mar 18, 2010
|Sap Ag
|Architectural Design for Plan-Driven Procurement Application Software
|Sep 18, 2008
|Mar 18, 2010
|Peer Marschall
|Architectural design for customer returns handling application software
|Mar 18, 2010
|Alexander Koegler
|Architectural design for service request and order management application software
|Mar 18, 2010
|Andreas Poth
|Providing supply chain control software as enterprise services
|Sep 18, 2008
|Mar 18, 2010
|Jacques Duparc
|Architectural design for time recording application software
|Mar 18, 2010
|Sap Ag
|Providing Supplier Relationship Management Software Application as Enterprise Services
|Dec 3, 2008
|Jun 3, 2010
|Sap Ag
|Architectural design for intra-company stock transfer application software
|Dec 3, 2008
|Jun 3, 2010
|Sap Ag
|Architectural design for make-to-specification application software
|Dec 11, 2008
|Jun 17, 2010
|Sap Ag
|Providing accounting software application as enterprise services
|May 29, 2009
|Dec 2, 2010
|Verizon Patent And Licensing Inc.
|Device classification system
|Jan 4, 2010
|Apr 21, 2011
|Bank Of America Corporation
|Designing security into software during the development lifecycle
|Jan 18, 2010
|Jul 21, 2011
|Isight Partners, Inc.
|Targeted Security Implementation Through Security Loss Forecasting
|Mar 7, 2011
|Sep 13, 2012
|Isight Partners, Inc.
|Information System Security Based on Threat Vectors
|Jan 17, 2013
|Bank Of America Corporation
|Designing security into software during the development lifecycle
|U.S. Classification
|717/104, 726/22, 717/107
|International Classification
|Cooperative Classification
|European Classification
|Sep 25, 2007
Owner name: MICROSOFT CORPORATION, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MIR, TALHAH MUNAWAR;REVURU, ANIL KUMAR VENKATA;MANOHAR, DEEPAK J.;AND OTHERS;REEL/FRAME:019877/0497;SIGNING DATES FROM 20070902 TO 20070924
Owner name: MICROSOFT CORPORATION, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MIR, TALHAH MUNAWAR;REVURU, ANIL KUMAR VENKATA;MANOHAR, DEEPAK J.;AND OTHERS;SIGNING DATES FROM 20070902 TO 20070924;REEL/FRAME:019877/0497
|Dec 9, 2014
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034542/0001
Effective date: 20141014
|Jun 24, 2015
|Fee payment
Year of fee payment: 4


text:
The Collection Blue pointelle knit cardigan
Item No.0570101080
Item No.0570101080
The Collection at Debenhams offers this soft blue cardigan with a wide pointelle knit. It has three quarter sleeves and a draped front with an open to edge fastening.
Sunday to Friday - order by 9pm
Saturday - order by 6pm
Monday to Sunday - order by midnight
Orders over £20 - FREE
Orders under £20 - £2
Show full delivery details
Subject to exceptions, Debenhams is happy to exchange or refund your purchase within 28 days of delivery. Please check here for more details on our returns policy and exceptions.
Open a Debenhams Credit Card today and receive:
Please note: if the amount you pay on your card is less than £500 after the 10% discount is applied, the 0% interest offer will not be available.
Credit available from NewDay Ltd to over 18's only. *Terms &Conditions applyFind out more & apply now

subset: commoncrawl


text:
Mayfield House Bed and Breakfast
No prices found through our partners. Please contact the business directly or check some of our recommended alternatives.
TripAdvisor Reviews Mayfield House Bed and Breakfast Tahoe City
Travel Blogs from Tahoe City
Tahoe Rim Trail of Magic
... in all that walking I was actually getting farther away from Canada. The reason, a cute lady and a funny guy talked me into adding 120 miles on to my hike and completing �the Tahoe Rim Trail. Now truthfully it didn't actually take to much convincing, the tahoe rim trail is something I have wanted to do for awhile, and I didn't have much of a reason to say no.� The Tahoe Rim Trail is a 173 mile trail that goes along the crest of the mountains ...
Our family and last day at the snow
... day especially for our last day of snow skiing. I have really enjoyed skiing and can't wait to do it again!! ; Ted's report: we went to Alpine Meadows to ski, we got the chair lift all the way to the top of the mountain, then we snow skied down it. I went 30km/h. At first I went on the kangaroo hop then it got boring so then I decided to go on the mountain and go fast. That wasn't boring. I ...
Day 2 .... On the slopes !
... turning and helped me slow down a bit and not go blasting down the hill like Jessica did the first two!! At a quarter past twelve we had lunch. We were only staying half day so Jessica and I followed mum and dad to the Gold Coast. A lot of the easy mountains were closed so we went on an intermediate slope. The two ski people in the lift told us it was nice and easy but it was not! At the start it was going all well until we got up to a sign that said ...
Enroute to NV
Friday morning we found the car covered in a layer of ice. The night brought freezing fog and crystalized everything from tree branches to my hula hoop. As the car defrosted, we struggled to repack the car. We headed back to Dustin's mom's house and found some sort of salesman sitting in his car on her property. He asked if I was Tammy, we said no but we are visiting her and we all entered ...
Bears, Bats and Fire Flies
... Is to prevent bears getting in them. There were a few in town last night apparently. Have not seen any yet - was hoping to see some at Yellowstone as they have both the brown and grizzly. Have seen a number of bison and elk on the trip so far. But by far the best thing to date were the fire flies near Boston. I did not know what was happening - i kept seeing these little ...
Other places to stay in Tahoe City
Cottage Inn1690 W. Lake Blvd., Tahoe City | B&Bfrom $65


text:
By Marco R. della Cava, USA TODAY
MOJAVE, Calif. Here are a few things you don'tdo when driving 200 miles an hour.
You don't think about family, friends or work. You don't worry about updating your Facebook page or missing any Tweets. You don't daydream.
You do concern yourself with surviving an experience that few mortals will savor. The reward is one extraordinary adrenaline rush, while the penalty for distraction includes the destruction of a super-pricey supercar and, um, damage to not only your own body parts but also those of the celebrated race car driver nervously riding shotgun.
"My priorities have always been screwed up," jokes Kent Meyers, 45, an aerospace network administrator from Torrance, Calif. He is paying for the chance to hit a speed at which most planes take off, one attainable only by Herculean cars.
He pops on a helmet as he prepares to shoehorn himself into a fire-breathing Mercedes-Benz SLR McLaren (list price: about $500,000) and zip down the 2.7-mile runway here at the Mojave Air & Space Port, a private facility that is home to Burt and Dick Rutan's SpaceShipOne.
"It's expensive, considering that it's just one cool day," Meyers says. "But it's about doing something that for the rest of your life you can say, 'Yeah, I did that.' "
Is this for real? Is it legal? Is it sane considering most of us experience such speeds only in video games?
Yes. Knock yourself out on private grounds. And anyone can play so long as they have a reasonable driving record and enough coins stuffed between those sofa cushions to pay the $4,995 that World Class Driving requires for eight hours in five cars pushing the 200-mph envelope.
"We hear the term 'bucket list,' but I don't really like it, as it implies you may die next," says Jean Paul Libert, a Belgian businessman and ex-racer who started World Class Driving in Europe and added a U.S. office in 2005.
Though the company's main focus is organizing public-road drives in hot cars, its 200-mph XTREME program has taken off. Many leisure businesses are contracting in a sour economy, but Libert is now expanding XTREME from its original Florida location to Texas and here in the California desert.
'It's far less than owning these cars'
So far nearly 90 attendees – about 50% – have hit 200 mph. Those who don't hit the mark back off the throttle out of fear or have track and weather conditions to blame. Once 200 drivers hit 200 mph, Libert says, he'll close this event and "dream up something new."
Libert concedes that five grand for a day's fun isn't cheap. "But it's far less than owning these cars," he says. His fleet includes Ferraris, Lamborghinis and a sleek Ford GT. "Times may be tough, but it doesn't mean people's dreams die."
Fantasy is the prime mover for the 11 folks (all are men; women are rare) huddled under a white tent that groans under the force of a cutting desert wind. Ranging in age from late 20s to nearing retirement, none is destined for race track glory. But all want to experience what a professional driver calls commonplace.
"It's about putting the pedal to the floor and not letting up, which we never get to do," says Alfred Lock, 60, of Los Angeles, a muscle-car lover who made the trip here with his son, Alan, 28, who bought him a spot in the class as a birthday gift.
"There's not much Dad gets pumped up about, but I knew this would do it," says Alan, a former Honda engineer turned stock trader.
The pair are inseparable in the morning training sessions, which find renowned Belgian racer Didier Theys and three other top pros leading the group through two exercises that familiarize students with the otherworldly performance characteristics of exotic cars.
The first involves making a 90-degree turn at 60 mph, triple the common-sense speed. To have a chance at hitting 200, drivers must turn onto the long runway from an adjacent road at a dead sprint, which requires a high-speed turn.
The second exercise involves taking a car up to about 90 mph and then easing on the brake just when your gut tells you to pounce on it with both feet. This is crucial when slowing the car from 200; braking too abruptly will throw the car's weight forward, which in turn can make the rear end swing violently. That's bad.
Eric MacGregor, 25, is having a go at the big turn while his wife, Natalie, 25, looks on nervously. "He's never done this before," she says as painful squeals emanate from the tires of the Ferrari F430 her husband is torturing.
"This isn't as easy as it looks," MacGregor says afterward. "But it is unbelievably entertaining."
His friends nod. The four have made the trek from Vancouver Island in British Columbia, guests of Doug Lockhart, 53, who is rewarding the key players in a recently completed heating and ventilation project.
This is Lockhart's second stab at 200; at a previous event in Miami, weather capped his speed at a mere 195. "That wasn't going to do," he says with a grin. "I needed to come back and nail it."
A haven for thrill-seekers
If you're thinking that Lockhart isn't quite normal, you'd be right.
Studies have shown that thrill-seeking humans have fewer receptors in the brain that monitor infusions of dopamine, the natural chemical that accompanies an especially exciting experience.
"Some events are interpreted two ways by the brain, either 'too much' or 'I feel alive,' " says David Zald, associate professor of psychology and psychiatry at Vanderbilt University. "The difference is the amount of dopamine."
Last year, he scanned the brains of 34 men and women and determined that those who sought out risky adventures were getting big shots of dopamine. Zald says humans probably have always pursued dicey pastimes. "In the old days, it was jumping on fast horses," he says. "Now it's driving cars 200 mph."
Drivers with both skill and capable cars routinely push and exceed the 200-mph barrier during organized rally races on closed Nevada highways.
"This sort of thing appeals to a limited amount of people, but those who love it are fiercely loyal," says Mike Borders, general manager of MKM Racing Promotions, which organizes legal races on highways, airstrips and Western salt flats. Next March, he'll stage the top-speed Mojave Mile at this very airstrip.
"Many people enjoy the rush, but they also like the control. I'll drive my car 200 mph on a closed highway, but I won't jump with a chute I didn't prepare," Borders says. "But I guess in the end, we all have some sort of defective gene."
At the main tent, racer Theys addresses the 200-mph gang, who are busy tucking away a lunch of Mexican food.
For the remainder of the day, they'll get a few attempts – depending on the fading light – to hit the magic number.
"I want everyone to be comfortable, because this is not a competition," he says, dead serious. "If you don't feel you want to go fast, do not go fast. Please."
Meyers breaks 200 mph on his first try in a Lamborghini LP 560, a menacing wedge of Italian beauty.
"It's so flat there is no way to really feel how fast you are going," he says, making his way to the McLaren for another stab at 200-plus. "That said, you know things are not normal. Which is the whole point."
Nearby, Rich Williams, 63, looks like he's just seen Santa Claus. Eyes agog. Mouth open.
"I feel like I just pulled the plugs out of my adrenal glands," says the San Jose-based technical writer. "I've sky-dived, fire-walked, zip-lined. I've even flown in planes that take you to zero gravity. But this is so bloody fast, it's hard to forget."
Each one of today's adventurers will return to their everyday lives with the knowledge, and an inscribed Lucite cube as proof, that they once sat a foot off the ground and traveled 300 feet (about the length of a football field) per second – and lived to tell the tale.
Not that that's enough.
"We had a good tail wind today," Libert says, announcing that Theys hit 212 during a demonstration run.
"Really?" says Rodney Baker, one of the Canadian contingent. "So what would it take for one of us to hit 230?"
Libert knows the answer: guts, endless pavement and Bugatti's Veyron, a $2 million steed whose top speed is 255.
Is a 250-mph program next? Make no mistake: If Libert arranges it, these crazies will come.
Guidelines: You share in the USA TODAY community, so please keep your comments smart and civil. Don't attack other readers personally, and keep your language decent. Use the "Report Abuse" button to make a difference. Read more.


text:
Andrew Yeadon
Andrew Yeadon is a musician, singer, songwriter from Co Durham currently running the highly popular TCR music project in Barnard Castle which serves to provide people from Teesdale with tuition, rehearsal and recording facilities and help and advice with music.
Forming his first band aged thirteen influenced by the likes of Guns'n'Roses and Iron Maiden his school bands took on a number of incarnations regularly featuring Ainsley Crishan on bass and Paul Elliott on drums, the group, then called 'The Scarecrows' hit a high when they were 16 when they were picked from 200 bands to play at Newcasatle's Mayfair club in the Northern final of the Panasonic Audio Rock School where they came third. After this the group took an unusual turn and recruited good friends James Whitburn on alto sax and Barnaby Fryer on tenor and did a set of soul covers dressed up in shades and bow ties under the name of 'The Prisoners' who proved very popular.Read more


text:
Paul Robertson's thoughts on Schubert
For nearly 40 years Professor Paul Robertson performed throughout the world as leader of the internationally renowned Medici String Quartet, of which he was a founder member. He is Radio 3's guide to the chamber music in The Spirit of Schubert. Here, he offers his personal analysis of Schubert's greatness.
There are many ways of measuring musical greatness and, like everyone else, when it comes to composers I have my own criteria. Naturally we would take as given that all 'great' composer possess superb technical mastery. But as we all know, there are many fine composers who, even despite their technique (and sometimes even perhaps because of it) somehow never, or only occasionally rise to 'greatness'.
Apart from an occasional tendency to explore 'divine length' I have never thought to question Schubert's place alongside the other immortals of the Western classical tradition. So to seek to define compositional greatness we clearly need to consider many other much more elusive qualities. Can these be measured or even articulated? and if so how many could we consider objective or impartial? I shall be very interested to read what you consider to be the unique qualities that marks out the genius of Schubert.
To start here are a few suggestions of my own:
- Nobility of aspiration (equal to, but never imitative of his hero Beethoven whose triumphs always seem to reward immense prior striving)
- Joyful music that is not trivial (as fine as Mozart but somehow more subjective)
Sad music that is without sentimentality (the best illustration of this is to listen to any of Liszt's many piano realizations of Schubert).
- Simplicity and complexity as best suited to the meaning and purpose of the music.
- Brilliance and invention that never supersede the emotional content of the music.
- An ability to take one further than could be achieved alone.
- A precision of affect - indeed I believe this to be one of the key roles for music.
- An original language (but not merely novel for its own sake)
- Sincerity (whatever that means!)
- A truthfulness of expression which renders the music somehow 'moral'
- Modesty
- Warmth and affection
- Simplicity of person (while we would all love to spend time with Mozart, Beethoven, Haydn, Brahms et al, wouldn't we also feel pretty daunted with most of them? I know I would.)
- Listen to Paul Robertson's Schubert Chamber Music introductions.
- Visit the Radio 3 Home Page for full details of The Spirit of Schubert.
- Consult the Schubert Lab for entertaining and enlightening explorations of Schubert's genius
- Visit Schubert's old haunts in Vienna with Sean Rafferty
All of this, and probably much else as well, is vital to musical greatness and we would all probably have a pretty clear notion as to who we believe should grace this list. However, with dear Schubert who more than fulfilled all the beautiful qualities above there is another much more rare set of personal qualities who, I believe set him apart even from many of the other 'greats':
But I feel sure that Schubert would have welcomed me into his home and fortunate circle without the least reservation or awkwardness.
I also believe that one can sense this beautiful quality within his music and that makes it very precious indeed to me.
- His music is great but he is not ever 'grand' - how rare is that? And how truly modern this makes him. This was a truly contemporary man with modern preoccupations and a generous and open spirit which is a rare treat in any age.
Comments Post your comment
Comment number 1.At 20:25 29th Mar 2012, Ludophile wrote:
As a description of the post-1822 Schubert, Paul Robertson's comments seem like a whitewash; can this be the composer of the string quartet in G D887? Personally I wouldn't visit him without a team of bodyguards ...
I tend to rate Schubert near the top of division 1 but not quite on a level with the other "greats": Beethoven, Bach, Mozart (definitely superleague); Haydn (superleague or top of div1?), Handel (near top of div1) ... if you will excuse this crude style of assessment. To address the issues raised adequately would take hours, which I don't have to spare, but I would offer the following key points.
1. Late Schubert is in touch with great (not necessarily "good") forces but he is not as consistently able as the other composers mentioned to deliver what (for want of better terminology) I shall have to call "positive directivity" or "positive vector" - by which I mean the harnessing and delivery of such forces and energies to empower the receiver of them (the listener to his music), rather than to make that receiver a (joint) victim of them.
2. Schubert's relative lack of humour makes it hard to place him alongside Beethoven or Haydn.
3. The very personal/"subjective" nature of Schubert's later style and intimate/private utterance militates against the making of "universal" statements. To my ears, when Schubert switches from intimate/private (in which he does indeed sometimes match the expressiveness and subtlety of other "greats") to a more public mode, the result often seems like hysterical outpouring; this is made worse by the tendency to very rapid shifts between the two domains, giving a sense that the discourse is out of control.
4. Late Schubert's love of "slow" (sometimes even plodding) sonata first movements (paving the way for Bruckner et al) weakens the sense of transition into another world when such a first movement is followed by the real slow mvt. (It is true that this may be partially compensated, eg: by the use of a remote or unexpected key for the real slow mvt.)
5. I feel that late Schubert contains a profound diagnosis of a troubled human being (himself) - with some (but not universal) generalisability [apologies for my clumsy words!]. A greater composer, such as Beethoven, can often provide not only the diagnosis but also the "medicine".
[This next bit is going to be controversial ...] I don't think that I would rate any composer later than Schubert as greater than him. So perhaps his misfortune is to be at the start of the long decline th
Comment number 2.At 20:35 29th Mar 2012, Ludophile wrote:
[last few words missing from my above post - perhaps it was too long?]
[the long decline] that is Romanticism/Modernism.


text:
We have listed all of the Valparaiso food pantries that we have found. With help from users like you we have compiled a list of some. If you know of a food pantry that is not included here, please submit new food pantries to our database by going to the ADD A LISTING link on the header of our website.
Help Us Help You
Food Pantries in Valparaiso, Indiana
Immanuel Lutheran Church Food Pantry
View Website and Full Address
Valparaiso, IN - 46383
(219) 462-8207
Provides a food pantry. Pantry hours: Tues Thurs 1pm - 3pmGo To Details Page For More Information
Christian Food Pantry
View Website and Full Address
Valparaiso, IN - 46383-3883
(219) 462-5615
Provides a food pantry. Pantry hours: Mon Weds 10 am - noonFood donations can be dropped at any of the sponsoring churches during normal business hours. (First Methodist, First Presbyterian, Trinity Lutheran, First Christian Churches) First Christian Church\'s office are open M-F from 9 am to 3 pm.All the basics are needed, Pork \'n Beasn, tuna, juices and cannGo To Details Page For More Information
First Contact Porter County
View Website and Full Address
Valparaiso, IN - 46383-5530
We are a conscientious, well-managed non-profit organization that can provide emergency food items, help with utility payment and emergency rent. Many Porter County churches provide financial support to us. All applicants are screened to determine actual needs and provided with assistance for food, rent and utilities. Financial counseling is provided at no cost to the applicant. Vouchers for furniGo To Details Page For More Information


text:
- 14 total posts
- 2 reviews
- 10 comments
- 2 questions
Reviews by bauhausfrau
Asked to Write Latisse Review - New York, NY
I think Latisse is very effective. It didn't do what I wanted it to do, so I stopped using it. I have very long eyelashes naturally, however they are also blonde and skinny. Supermodel lashes. Latisse made them even longer, but I was hoping for more thickness. I didn't get any more thickness,... READ MORE
Gifted Doctor - Greenwich, CT
I've gone to Dr. Raskin a few times for Botox and facial fillers. She does a wonderful job of restoring your natural look before fat loss from aging. She has a great eye for what improvements will make the most impact, and the most efficient way to go about it. She has a pleasant, charming... READ MORE
Questions from bauhausfrau
Any suggestions for loose skin on abdomen and armpits? (photos)
I'm 5'4", 106 lbs. For the most part my body looks like it did at 25, but I'm over 40 now so my skin just isn't what it used to be. I have 2 areas that really bother me and I... READ MORE
Recent comments from bauhausfrau
This is a helpful post. You're very beautiful, but I can see why you may have wanted your nose a little smaller. Mine is exactly the same from another doctor. After several years I'm still not completely happy with it because it really... READ COMMENT
So, did you have fat transfer done only to the nasolabial folds & under the eyes? You look great, by the way. READ COMMENT


text:
The origin of Navy Information Operations Command Pensacola dates back to the spring of 1986, when a detachment was established to lay the foundation for what was to be an extensive undertaking for Naval Security Group Command (NSGC). The rapid development of technology required a commitment to keeping the Fleet and Shore Cryptologic Automated Information System capabilities technologically current. Naval Security Group Activity (NSGA) Pensacola was thus commissioned in July of 1993. Housed in a 67,000 sq. ft. facility aboard Corry Station Naval Complex, NSGA Pensacola would soon serve as the center of excellence for Automated Information Systems for Navy cryptologic systems. On 30 September 2005, after the formal disestablishment of Naval Security Group Command, NSGA Pensacola was realigned under the newly formed Naval Network Warfare Command (NETWARCOM) and changed its name to Navy Information Operations Command (NIOC) Pensacola. On 29 January 2010, U.S. Fleet Cyber Command (FCC) was established and U.S. 10th Fleet was recommissioned to align the various staffs with the operations and type commander model used throughout the Navy. Under FCC/C10F, NIOC Pensacola has maintained key mission areas as a member of the Service Cryptologic Element, as well as pioneering the development, expansion and capabilities of fleet and national cyberspace operations.
In 2013, NIOC Pensacola demonstrated it was the Navy's Combat Support Team (CST) Center of Excellence, building and establishing all five Navy CSTs in support of USCYBERCOM's Cyber Mission Force (CMF). The CMF is a first-of-its-kind force presentation model for cyber in the Department of Defense. Currently, four CSTs perform target development, target discovery and analysis, planning and synchronization and intelligence and malware analysis. CSTs support Combatant Command operations and war plans that enable delivery of cyber effects against an adversary in cyberspace.
US Navy Recruiting | No Fear Act Data | FOIA
US Navy | US Marine Corps | Navy Reserves
US Navy FAQ | USA.gov | Section 508/Accessibility