Ok, registration actually took place yesterday. We arrived early and decided to go ahead and pre-register to make things easier on ourselves.
Talk about easy... they did not ask for any form of ID. We walked up to the counter, looked down at the name tags all layed out and easy to read, said a name, and were handed a lanyard, badge, bag, shirt, and CDs. No questions asked. Nothing to sign.
Not a great first impression.
Designing Service Oriented Applications
Service Oriented Architecture
SOA History
CORBA, Tuxedo – prior platforms/tools that SOA has been implemented in. Many other attempts with other tools (and these) failed.
Case Study (loose)
Created a group called the Business Objects Service Group and they were assigned the task of creating reusable services. Service talented developers were put into BOSG. Other (front-end) developers placed in business units to create apps that consume services.
Separation of Function from Interface put the company at a competitive advantage – able to react to change in the market place much faster (took time to build library of services) Doesn’t happen overnight.
System developed in CORBA – now in EJB. Handles 2 Billion transactions/month
Proper architecture requires more than one architectural view
Make it easy to enable the developers to build applications that follow the architectural standards
SOA is concerned with the independent construction of services that can be combined together
Service – encapsulates a unit of work, made available through a service contract
Dynamic Binding, Loose Coupling, Modular and self contained, composable
BPEL – Business Process Execution Language – used inside a business service; usually provided by the technology platform
Business Process Level (BPM) – manage process; checkpoint, auditing, security, etc. also determine sequence/series of services changed together to achieve a need
Salesforce.com, eBay, Amazon, WebSuite – provide third party Web services
Majority of corporate expenditure for application development is on Maintenance. Next highest number is on Integration. Last is on New development.
Coupling
Loose Coupling – Want to make it possible for the creator of the service to make adjustments without requiring the consumer to alter their use of the service. Decouple the life cycle of the consumer from the life cycle of the provider.
Synchronous vs. Asynchronous – not really significant in SOA. These terms are more specific to the requirements of the system, but not specific to SOA and decoupling. Most SOA implementations will use both.
Interface and Implementation – allows a service to change without requiring changes of the service consumers. Important in an SOA architecture. SOA ensures the interface contract is the ONLY means of interaction.
Publication, Discovery and Binding
Registry exists as a broker
Service is published as a service definition to the Registry
Service Provider registers as a provider of an implementation
Consumer requests a service from the registry
Registry makes a decision and provides “handle” to the service.
Consumer then connects to service
SOA integration
Integrate Once, use many, consistent access, lower total cost
Adaptable to change
Incremental approach – start small, add new integration services over time as part of specific projects
Flexibility increases with each new service
SOA and Web Services by Eric Newcommer – “Not a bad book” – decent book RE: Web services, but weak regarding SOA overall.
Best Practices in SOA Development
MDA Overview
Model Driven Architecture
Business Model -> Application Model -> Implementation Model -> Code
Model – a representation of the system. A model describes part of the function, structure and/or behavior of a system.
Formal Model – a representation of the system conforming to rigorous rules All Model Based Development models are formal
Model should be platform independent – independent of the language/technology used to build it. Also independent of any hardware.
PSM – platform specific
PIM – Platform independent
Tools exist that can generate code based on well defined models. Use of these tools is convenient and saves cost, but regardless, the process of building models accurately (theoretically) makes app dev/maintenance easier and more flexible.
Applying MDA to SOA
More SOA app initiatives are bottom up rather than top down. Top Down is based on a Business Process Model. Bottom Up is trying to leverage an existing service or service enable legacy systems. Best approach is “middle out”
Process Overview
· Understand Use Cases – not too detailed
· Specify Scenarios – show flow of use cases with actors
· Design/Align Information Model
· Understand Overall Context
· Look for appropriate patterns
· Identify Service and Interface Style
· Define Documents
· Define Service Implementation
· Look for appropriate patterns
· Information Transformation follows data flow
SOA should implement the most important things first; shared information and shared functions.
Threat Modeling: Creating Secure Applications
Agenda is based on two books:
Writing Secure Code and Threat Modeling
Threat Modeling (book) – good place to start, but getting long in the tooth. Great if you are just getting started.
void main() {
char buf[512];
gets(buf);
}
The above is vulnerable to a buffer overflow.
Java Principle – As you work on an application, it gets better and better.
This is a fallacy. The likelihood of bugs is no more or less with each release.
“Security is all about data. Attacks are via data. What they are looking for is data.” therefore
“The ultimate safe program is one that takes in no data and produces no results.”
What are threat personas?
A systems’ anti-users
- based on real-world data. There are five behaviors and eight actual personas
“One person’s feature is another person’s exploit”
Author
Vandal – Curiosity; usually script kiddie
Trespasser – after personal fame – want to make a mark and get credit for it - usually hobbyist/hacker
Personal Gain – Thief – actually after the data to take advantage of it – usually hobbyist, but many expert
National Interest – spy – experts and specialists
Some Important Definitions
Threat Agents – someone who could do harm to a system (adversary)
Threat – An adversary’s goal
Threat Tree – A graphical representation of security-relevant pre-conditions in a system
Vulnerability – a flaw in the system that could be exploited
Asset – Something of value to the valid users and adversaries alike
Attack – When a motivated and sufficiently skilled threat agent takes advantage of a vulnerability
Threat Model – describes a system’s threat profile
Classic Threat Modeling
Collect Background Information -> Model the System -> Determine Threats
Collect Background Information
Identify Scenarios
how the system is intended to be used (or not intended) in deployment
Help us understand what was considered in security model in the first place
Identify External Dependencies
Dependencies / requirements outside of our system/model
Implementation Assumptions
Assumptions should be validated on completion of implementation
Identify external security notes
Counterpart to external dependencies
Identify internal security notes
Makes model more clear
Explain tradeoff made in design or implementation of the system that affect security
Model the System
Modeling is critical to determining threats; helps us understand adversary’s view of the system; helps team understand internal workings
Identify Entry Points
Define the boundaries of the system being modeled
List all places where the system consumes or provides data including actions on behalf of third parties
Often obvious, but may not be. Reading files from the system is an entry point.
Identify Assets
Those things (concrete and abstract) that could be targets of an attack by an adversary
Assets should be nouns
Assets can be widely varies; data in a database, network coherency on a peer to peer application
Identify Trust Levels
Have preconditions (authentication)
Trust levels characterize either entry points or assets
Trust level specific to the entry point of asset
Create flow diagrams / process models
Describe processing on the threat path
Threat Path is the processing that occurs based on the input to the enumerated entry points
Follow the processing from entry point – determine what it does (or can do to data)
Create Data Flow Diagrams
Context Diagram
Keep modeling until there are no more multi-processes
Building a DFD
Identify the actors and where data moves in and out
Break-down HOW data moves in and out
Keep these at the high level
Determine Threats
Enumerate threats – creates a threat profile
Threats with valid attack paths are vulnerabilities
Threats are verbs
STRIDE – types of threats to a system (all known threats to date fall into these types)
Spoofing – pose as another user
Tampering – modification of data
Repudiation – deniability of malicious acts
Information (disclosure)
Denial of Service
Elevation of Privilege
DREAD – means of characterizing the risk associated with a vulnerability
Damage Potential – extent of possible damage
Reproducibility – how easy is it repeat the attack with success
Exploitability – Effort required to execute the attack in the first place
Affected Users –ratio of installed instances affected is exploit is widely available
Discoverability – how likely the unpatched exploit is to be found by others
CIA – Confidentiality / Integrity / Availability
Threat models should include review from outside parties.
Conclusion
So far, so good. The SOA class was too slow to start and too quick at the end. Bored me and then lost me. Security course was very good. Lots of useful tools and examples. Nice exercise. I'm definitely growing more and more interested in this aspect of our field....
No comments:
Post a Comment