Architecting for the cloud elasticity security

Architecting for the Cloud

Len and Matt Bass

Elasticity

Link to Yesterday’s lectures

http://www.slideshare.net/lenbass/architecting-for-the-cloud-scabilityavailability

Topics

Scalability is about acquiring resources but once they are acquired, they still must be used.

Elasticity is about how to use the resources.

This requires understanding

• Concurrency

• State

and their interactions

3

What is concurrency? • Concurrency means

performing several activities simultaneously

• Concurrency is used to improve performance.

4

How do concurrent activities come to be?

• Explicitly through your code creating a new thread or process.

• Implicitly through some support system creating a new thread or process – Operating system – Web server – Database management system

• Implicitly through the infrastructure creating a new virtual machine – Elasticity in the cloud – During deployment of your system

5

Key concepts

• Atomicity – An atomic operation cannot be divided. It is all or nothing.

• Time – It takes time to perform an operation.

• Computation • Messages transferred over a network • Reading/writing information from a disk (rotating or solid state)

• Dependency – Coordination among concurrent activities is necessary if

they are sharing resource or results

• Problems arise because operations take time and can be interrupted. I.e. are not atomic.

6

Synchronous vs asynchronous

• Synchronous coordination between two concurrent processes means that process A sends a message for process B and waits for a response.

• Asynchronous coordination means that process A does not wait for a response.

– It can poll for a response

– A response from process B can be sent as an event.

• In either case, coordination takes time and so coordination is not an atomic operation.

7

Some problems with concurrent activities

• Time stamps. • Many protocols involve putting a time stamp on messages

for error detection and ordering purposes.

• Time stamps are often used to identify log messages used for debugging problems.

• In some environments, e.g. stock market, trades must be satisfied in the sequence in which they arrive.

• Race conditions – two processes are simultaneously accessing the same resource.

• Inconsistency – If two activities are being performed simultaneously, data may become inconsistent.

8

Clock synchronization

• Suppose two different computers are connected via a network. How do they synchronize their clocks?

• If one computer sends its time reading to another, it takes time for the message to arrive.

• NTP (Network Time Protocol) can be used to synchronize time on a collection of computers. – Accurate to around 1 millisecond in local area networks

– Accurate to around 10 milliseconds over public internet

– Congestion can cause errors of 100 milliseconds or more.

9

Suppose NTP is insufficiently accurate

• Financial industry is spending 100s of millions of dollars to reduce latency between Chicago and New York by 3 milliseconds. – Well within error range of NTP

• GPS time is accurate within – 14 nanocseconds (theoretically) – 100 nanoseconds (mostly)

• Timestamp messages with GPS time – Used by electric companies to measure phase angle – Used by Google to coordinate time across all of their distributed

systems. – Requires specialized hardware and installation not yet cheaply

available.

10

Example of a race condition • Suppose withdrawals are being made from a bank

account. If there are two users simultaneously withdrawing, the following sequence can occur.

11

User 1 User 2 Acct amount

1000

Read account (1000) 1000

Read acount (1000) 1000

Withdraw 100 (900) 1000

Write new amount (900) 900

Withdraw 100 (900) 900

Write new amount (900) 900

Example of inconsistency

• A cache is frequently used to keep data locally rather than requiring it to be fetched for each request. Web browsers, for example, cache web pages.

• For every request, the sequence is 1) look in cache to see if the request can be satisfied with the contents of the cache

2)If no, then retrieve information and return it to the requester and place it in the cache.

• Now suppose the web page is changed at its source

• Retrievals of the web page from the cache will retrieve an out of date version of the web page.

12

Solutions bring new problems

• One technique to prevent race conditions is to lock critical resources.

• Can lead to deadlock – two processes waiting for each other to release critical resources – Process one gets a lock on row 1 of a data base – Process two gets a lock on row 2. – Process one waits for process 2 to release its lock on

row 2 – Process two waits for process 1 to release its lock on

row 1 – No progress.

13

Yet more problems

• Locks are logical structures maintained in software or in persistent storage.

• Getting a lock across distributed systems is not an atomic operation. – It is possible that while requesting a lock another

process can acquire the lock. This can go on for a long time (it is called livelock if there is no possibility of ever acquiring a lock)

• Suppose the virtual machine holding the lock fails. Then the owner of the lock can never release it.

14

Is there a solution?

• The general problem is that you want to manage synchronization of data across a distributed set of servers where up to half of the servers can fail.

• Paxos is a family of algorithms that use consensus to manage state concurrency. Complicated and difficult to implement.

• An example of the problems – Choose one server as the master that keeps the

“authorative” state. – Now master server fails. Need to

• Find a new master • Make sure it is up to data with the authoritative state.

Luckily

• Several open source systems are now available that

– Implement Paxos or an alternative consencus algorithm

– Are reasonably easy to use.

• Two such systems are

– Memcached – discussed at the end of this lecture

– Zookeeper – discussed in tomorrow’s lecture.

In general

• Introducing concurrency will improve performance but also introduces problems.

• Concurrency is a constant consideration when architecting for the cloud. – Coordinating activities across concurrent processes is

difficult and prone to many errors. – Allowing for failure complicates coordination of

activities.

• Systems are available to provide concurrency for small amounts of data without your having to worry about the details.

17

Topics

In order to understand how to achieve elasticity you must understand

• Concurrency

• State


18

Recall Load Balancer

• Client makes a request that is routed to a server through a load balancer

Message sequence – client makes a request

Servers

Clients

Load Balancer

Message sequence- request arrives at load balancer

Servers

Clients

Load Balancer

Message sequence – request is send to one server

Servers

Clients

Load Balancer

Message sequence – reply goes back to client

Servers

Clients

Load Balancer

Message sequence – now client makes second request – does it matter which server it goes to?

Servers

Clients

Load Balancer

? ? ?

“Sticky” http requests

• Normally load balancer will route requests depending on load of servers attached to it.

• This is why it is called “load balancer” • Client can request to be always routed to same

server. This is done by making a “sticky” http request.

• Dangerous for two reasons: – Server may be overloaded and response delayed – Server may have failed and no response is

forthcoming.

• We assume non sticky http requests.

Suppose message is routed to an arbitrary instance.

• Understanding what happens requires a digression into state.

• A computation has two inputs

– Instructions

– Data

• The data input of a computation is called the state.

How does this work with functions?

• Consider a function that counts how many times it is called.

• Option 1:

int countv1()

{

int i = 0; //declare i and initialize it to 0.

i = i + 1; //add 1 to the last value of i

return i;

}

• The function count remembers i from one call to the next.

• State is maintained inside the function – it is stateful

27

Option 2

int countv2(int i)

{

int a;

a = i + 1; //add 1 to the last value of i

return a;

}

• The function count does not remember the value of i from one call to the next.

• The client must pass the last value returned.

• State is passed into the function. The function is stateless

28

Option 3

int countv3()

{

int a;

a = dbase_get (“count”); //retrieve current value

a = a + 1; //add 1 to the last value of a

dbase_write(“count” a); //save current value

return a;

}

• The count is stored in a database.

• Neither the client nor the function remembers the value.

• The function is stateless.

29

What is the difference?

• In option 1, the function kept track of the count value.

• In option 2, the client must keep track of the count value.

• In option 3, the count value is kept in an external database.

• In each case, the state (count value) must be kept somewhere.

30

Suppose the functions are packaged as processes in virtual machines

Option 1 Option 2 Option 3

Countv2 Countv3 Countv1

Client

DB

Processes communicate via messages

• Message from client to process is call

• Message from process back to client is return of a value

32

Now suppose each process has two clients – what is computed by option

1?

Countv1

What is computed by option 2?

Countv2


Countv3

DB

Where state is kept matters

• Option 1 – counts number of times called by either client. Process remembers value

• Option 2 – counts number of times called by each client. Client remembers value

• Option 3 – counts number of times called by either client. Database remembers value.

Options 1 & 3 calculate different things than option 2.

36

Now suppose each process has two instances– remember the load balancer

Countv1 Countv1

Load balancer distributes messages to servers


38

Countv1 Countv1


Countv2 Countv2

What is computed by option 3 ?

Countv3 Countv3

DB

Now what do the options compute?

• Option 1 – each instance of the function countv1 computes how many times it was invoked

• Option 2 – each instance of the function countv2 computes how many times each client invoked either instance

• Option 3 – the database contains the number of times either instance was invoked by either client.

41

What have we seen?

• When there was one instance of a client and one instance of the count process- all three versions were identical

• When there were two clients and one instance of the count process– two versions were the same, one was different

• When there were two clients and two instances of the count process– all three versions produced different results.

42

Message so far

• How state is managed is important and will lead to different results when there are multiple instances of clients or functions.

• Now we return to elasticity

• Remember the sequence?

43

Message sequence – client makes a request

Servers

Clients

Load Balancer

Message sequence- request arrives at load balancer

Servers

Clients

Load Balancer

Message sequence – request is send to one server

Servers

Clients

Load Balancer

Message sequence – reply goes back to client

Servers

Clients

Load Balancer

Message sequence – now client makes second request – does it matter which server it goes to?

Servers

Clients

Load Balancer

? ? ?

It depends where state is kept

• If state is kept in the client, then it does not matter since the client keeps track of the calls

• If state is kept in a database then it does not matter since the results are kept external to the servers

• If state is kept in the server then it does matter since sending message back to server 1 will give different result than sending it to server 2.

Keeping servers stateless enables elasticity

• A new instance of a server can be – Created/stopped

– Registered /unregistered with the load balancer

– Placed in/removed from service

without Requiring the client to be aware of which server instance it is interacting with

Requiring that clients be notified if a server is taken out of service

Types of State

• Session state

• Client side state

• Server side

• Persistent

What is a session?

• A session typically refers to a series of interactions between one client login to a system and the termination of that login – whether through logging out or through timing out.

• A session can also span multiple logins. E.g. Netflix keeps track of where you are in a movie and returns you to that location the next time you log in.

Session State

• Session state is information that persists for a session. We are considering a single login here. The multiple login case is a special case of persistent state.

• What happens when you login – When you successfully login to a service, the service

returns a code that identifies you. This is the session ID.

– Other information can also be included such as MAC address (to prevent man in the middle attacks).

– It is typically managed on the client side. Your browser does all of this.

Client Side State

• This can be difficult if there is significant state to save, however

– This means you’ll need to pass all of this state with each request

– This requires more network overhead

• This also means you’ll need to store data on the client machine

– This can have security implications

Stateful Services

• If your services are stateful that makes scalability more difficult

• If you’re able to design your system such that the services are stateless you’ll make scaling much easier

• If an operation is dependent on the results of a previous operation it’s more difficult to make services stateless

Management of state between services and persistent tier

• Non client side state can be either kept in the services or in a persistent store.

• The choice depends on the volume of data, the latency involved, the synchronization needs for the servers and the time the state is expected to persist.

Important latency numbers

• Main memory reference 100 ns • Send 1K bytes over 1 Gbps network 0.01 ms • Read 4K randomly from SSD. 15 ms • Read 1 MB sequentially from memory 0.25 ms • Round trip within same datacenter 0.5 ms • Read 1 MB sequentially from SSD 1 ms (4X memory) • Disk seek 10 ms (20x datacenter roundtrip) • Read 1 MB sequentially from disk 20 ms (80x memory, 20X SSD) • Send packet CA->Netherlands->CA 150 ms

57 * dean-keynote-ladis2009_scalable_distributed_google_system

Implications of latency numbers

• State stored in persistent storage (disk or SSD) will take longer to fetch than state stored in memory.

• State stored in a different datacenter will take longer to access than state stored locally, especially across continents.

• Persistent store is typically replicated both for performance (latency) reasons and for availability (failure) reasons.

• => keeping data consistent across different occurrences of it is important but difficult.

Topics

In order to understand how to achieve elasticity you must understand

• Concurrency

• State


59

Keeping data consistent

• We will discuss persistent data consistency when we discuss databases.

• Memcached is an open source tool that provides in-memory synchronization of data across different instances of a service.

• Now consider these layers deployed onto multiple servers.

Layers of a service

Business logic for the service

Memcached

Memcached in multiple servers

• Memcached keeps small amount of state in all servers consistent.

• At a small cost in latency as long as they are in same physical location.

Memcached Memcached

Business logic

Business logic

When to use Memcached

• Data must be synchronized among servers.

• Memcached takes care of concurrency issues

• Data is relatively small – One object < 1MB

– Total memory used per server depends on how much you are willing to give it per server since it is stored in memory, not on a persistent store

• Lifetime of the data should not exceed time any of the servers are alive. I.e. if all the servers die, then the data disappears.

Summary

• The cloud doesn’t guarantee elasticity

• You’ll need to design your system to be elastic

• State management, your storage solution, and consistency, are all factors that you’ll need to consider

QUESTIONS?

Architecting for the Cloud

Introduction to Security

Agenda

• What is security?

• Understanding the threat

• Architectural approaches to security

• Designing for security

• Summary

Agenda





• Summary

Your Experience

• Think about your past experience

– How have you thought about security?

– What steps have you (or your organization) taken to protect the system?

• Do you remember Assignment 2?

– Security was equivalent to having a login feature or encryption

Security … What is it?

• What do we mean when we say security?

• In your experience what does this mean?

Let’s Look at some Examples

Fort Knox

• Fort Knox is a US Army post in Kentucky

• In addition to housing various US Army functions it is also the home to a gold bullion depository

– 5000+ tons of gold housed there

Security

• What is the business asset that needs protection in this case?

• What does protect mean here?

What About the CIA?

• The Central Intelligence Agency (CIA) is a US civilian intelligence organization

• Primary purpose is to collect information about foreign governments, corporations, and individuals

• It uses this information to influence public policymakers

– It does at times engage in tactical operations as well

Security

• What is the business asset that needs protection?

• What does protect mean in this case?

Power Distribution

• What would security mean if you have a system that manages the power grid?

Business Context

• The business need differs from one context to another

• Organizations have assets they need to protect

• They need to protect these assets for different reasons – Business continuity

– Liability reasons

– Regulation

– Protection of IP

– …

Security – A Set of Concerns

• The related concerns are typically classified as “security” concerns

• In software these concerns are typically:

– Confidentiality

– Data integrity

– Non repudiation

– Availability

Confidentiality

• The property that reflects the extent to which:

– Data and services are only available to those that are authorized to access them

• Is this a concern for a Museum? How about a Financial Institution?

Integrity

• This property can also refer to data or services

• It reflects the extent to which data or services can be delivered as intended

• E.g. hopefully the grade that we have recorded for you in this course is correct …

Non Repudiation

• Nonrepudiation is refers to the ability to guarantee that the sender can not later repudiate or deny having sent the message

• It can also refer to the guarantee that the recipient cannot later deny having received the message

• When might this be important?

Availability

• This is the property that reflects the extent to which the system will be available for legitimate use

• A denial of service attack is meant to disrupt the availability of a system

Protection Against What?

• Now that we understand the business asset, what are we protecting against?

• In order to appropriately protect our system we need to understand the threat

• Let’s look at example exploits …

Agenda




• Summary

Threat Sources?

• Insider threats

• Physical threats

• Social engineering

• External attacks

Who is Leveraging These Techniques?

• The art of hacking has gone from an individual activity to a highly coordinated and sophisticated effort

– It can now be quite lucrative as well

• Today many legitimate and illegitimate organizations routinely launch attacks

– Just run a port scan detector on your system

• Let’s look at the progression of exploits

Progression of Exploits

• Mischievous individuals:

– The first generation of hackers were technical youth performing mischievous acts

• Revenue generation: a proof of concept

– These were the first example of hacking for money

– Still small scale

• Organized crime

– These were criminal organizations involved in larger scale criminal activity

• Widespread adoption – The infrastructure needed to launch Cyber attacks is now widespread

– The barrier to entry has been lowered

– Legitimate entities enter the game

• Advanced persistent threats

Hackers – First Generation

• In the 1990s hackers were by and large not malicious

• They were in it for the challenge

• Notable hackers – Kevin Mitnick

– Chen Ing-Hau

– Jeffery Lee Parson

– Sven Jaschan

Kevin Mitnick

• Broke into dozens of computer networks – Pac Bell

– DEC

– MCI

– Digital

– …

• Wasn’t in it for financial gain

• Largely used “social engineering” techniques

• Arrested twice 1988 and again in 1999

Mitnick 1995

Mitnick’s Techniques

• Largely used “social engineering” to gain access to passwords and insider information

• Used this information to gain access to target system

• Mitnick claims that he never “hacked” a system (still a point of controversy)

Chen Ing-Hau

• University student that created and released the CIH virus in 1999

– Wrote the virus to “make a fool of the software vendors”

• Virus that would render the computer essentially inoperable on a specified date

• Became one of the most widespread viruses

• Some version of this virus have showed up multiple times

CIH Virus

• Exploited vulnerability in Windows 95, 98, & ME

– Along with an issue in various BIOS chipsets

• Would overwrite the first megabyte of the hard drive and attempt to overwrite flashdrive

• Result rendered the pc inoperable

Jeffery Lee Parson

• Was 18 when he confessed to be the creator of Blaster worm

• A Chinese “cracking” collective reverse engineered a MS patch

• Parson created a worm to exploit a buffer overflow issue

• Affected DCOM’s RPC service

– Worm could spread without users opening an attachment

Blaster Worm

• In addition to changing RPC service it would

– Change registry to launch msblast.exe

• Worm would launch a distributed denial of service attack from infected computers

– Attack was against windowsupdate.com

• Sent messages to Bill Gates

Sven Jaschan

• Authored Sasser and Netsky worms

• Claims to have written them to remove Mydoom and Bagle worms

• Worms were responsible for 70% of the infections in 2004

Netsky

• Sent out as an email attachment

• Contained insults aimed at the author of Mydoom and Bagle

• Other symptoms included “beeping” in the early morning hours of specific dates

Sasser

• Would connect to computers through a particular port that was often open by default

• Exploited a buffer overflow

• Would shut the computer down after displaying a shutdown timer

Cyber Criminals – Proof of Concept

• After the turn of the century a new breed emerged

• They took the techniques employed by the mischievous youth and used them for monetary gain

• These were the first real “cyber criminals”

– Ferid Essebar

– Attilla Ekici

– Jeanson James Ancheta

Ferid Essebar & Attilla Ekici

• The two people behind Zotab computer worm

• Worm affected CNN, ABC News, NY Times, US Dept of Homeland Security, …

• Intention was to facilitate credit card forgery scams

Zotab

• Exploited vulnerability in Windows 2000

• Caused the computer to restart continuously

• Files would be created with every reboot

• Spyware was installed on the system

– The spyware remained after the virus was removed

• The goal was to facilitate scams (for money)

Jeanson James Anacheta

• First person to be arrested for controlling a large number of hijacked computers

• Created a large Botnet

– Network of bots or “software robots”

• Offered his collection of bots for hire

• Leveraged rxbot to increase his network

Rxbot

• Contained a proxy server

• Server can be spawned by a remote attacker

• Typically used for denial of service attacks

Cyber Gangs

• “Organized” crime gets involved

• Coordinated attacks against high value targets

• Often involve groups and large sums of money

• Examples

– Yaron Bolondi

– Maria Zarubina

– Albert Gonzalez

Yarib Bolondi

• Part of a gang that attempted to steal £220 million from Japanese bank

• Used keylogging to gain access to bank’s computers

• Software is installed on employees computers

– Via malware or other virus

Maria Zarubina

• Part of a gang that used cyber attacks as a means for extortion

• Attacked British “bookmakers”

– Agreed to stop attacks if ransom was paid

• Used denial of service attacks to shut down gambling sites

• Would then threaten additional attacks unless payment was made

Albert Gonalez

• Responsible for largest credit card theft in history

• Stole and resold more than 170 million cards

• Used SQL injection to introduce “malware backdoors”

– These allowed packet sniffing attacks

• Targets included Target, TJ Max, Dave & Busters, 7-eleven, JC Pennys, …

ARP Spoofing

• Used to attack an ethernet network

• Allows attacker to “sniff” data on a LAN and modify or stop the traffic

• Attacker sends a spoofed ARP message to Ethernet LAN

• “Man in the middle” attack

– Attackers computer masquerades as destination computer and gets intended traffic

Advanced Persistent Threat

• Today we’ve started to see a new class of threat emerge

• These threats are against specific high value targets • They are characterized by coordinated activity taking

place of a long period of time – The individual actions may seem isolated

• The perpetrator doesn’t act on the exploit until sufficient penetration has been achieved

• Has anyone heard of Stuxnet? • How about Gauss or Flame?

Software as a Weapon

• In 2010 Iran announced they put their nuclear program on hold

– No one was sure why

• It turns out the reason was that more than 1000 centrifuges in their uranium enrichment facilities were destroyed

• How were these centrifuges destroyed?

– By the first known weapon that was 100% software

Stuxnet

• Stuxnet was a worm that infected SCADA systems made by Siemens

– Think power plant and power distribution control systems

• It was capable of

– Increasing the pressure inside nuclear reactors

– Switching off oil pipelines

• Additionally it would report that the systems were operating normally

Sophisticated Attack

• Why is stuxnet special?

• First, it didn’t use a forged security clearance

– It used a genuine security clearance that was stolen

• Second, it had a specific target

– It infected many systems worldwide but remained dormant until it found the systems controlling the intended target

• Third, it exploited not 1, but 20 zero day vulnerabilities

Response

• Iran responded to the attack with an open call for hackers to join the Iranian Revolutionary Guard

• Iran now has reportedly amassed the 2nd largest online army in the world

Side Note

• Stuxnet is now open source

• This is code that is capable of crashing power plants and disrupting oil pipelines

• Go to youtube and search for stuxnet

– You’ll get many videos of people dissecting stuxnet …

Advanced Persistent Threats

• Stuxnet is an example of what we call “Advanced Persistent Threats”

• In some cases exploits are not opportunistic reactions to discovering a vulnerability

• They are coordinated multipronged attacks that can take place over an extended period of time

Coordinated Attack

• Intruders will look for some way to find access to a system

• They will then try to move laterally until they are able to access the intended target

• This can take days, weeks, months, or even years

Email

What’s the Point?

• Almost all of these incidents exploited vulnerabilities

• These vulnerabilities came along with the commercially available software used in the attacked systems

• Vulnerabilities continue to exist in the software that we use

Vulnerabilities

• Many organizations (legitimate and illegitimate) try to find these vulnerabilities

– CERT is an example of such an organization

• Organizations like CERT would inform the developers of the software of the vulnerability

• Historically companies were slow to react

• CERT didn’t want to release it publically without a fix being available

• So CERT would notify the organization and then release the vulnerability publically after a given time elapsed

X Day Vulnerabilities

• Vulnerabilities are characterized by the time since they were made public

– 1 day vulnerabilities were released 1 day ago

• The newer the vulnerability the less likely it is to be patched

• Zero day vulnerabilities are those that the manufacturer doesn’t yet know about

– Clearly these are the most attractive to attackers

Vulnerability Market

• A market has emerged for these vulnerabilities

• If you discover a vulnerability you can sell it

• The value of the vulnerability is determined by:

– The “day” of the vulnerability

– The number of instances of the software containing the vulnerability

Selling The Vulnerability

• Many entities buy these vulnerabilities – Governments (including the US)

– Organized crime syndicates

– Individuals

• Prices range from $10 - $250,000 or more – Depending on the exclusivity of the sale as well as the value of the exploit

• Check out: – http://www.forbes.com/sites/andygreenberg/2012/03/23/shopping-for-zero-days-an-

price-list-for-hackers-secret-software-exploits/

– http://www.zdnet.com/blog/security/black-market-for-zero-day-vulnerabilities-still-thriving/2108

http://www.forbes.com/sites/andygreenberg/2012/03/23/shopping-for-zero-days-an-price-list-for-hackers-secret-software-exploits/
























http://www.zdnet.com/blog/security/black-market-for-zero-day-vulnerabilities-still-thriving/2108
















Exploit Auction Houses

• There are now auction houses that sell vulnerabilities (or exploits)

– Like the ebay of exploits

– In fact exploits were originally sold on ebay

• It’s actually legal to sell these exploits

– Even though the attacks themselves may be illegal

Exploit as a Service (EaaS)

• Believe it or not you can now get a service to manage your attacks

• One issue if you’re going to launch an attack is finding a “bulletproof” provider – A provider willing to host a malware server

• These services will provide “exploit kits” and manage the hosting

• In some cases they even offer analytics for the consumer’s campaigns (think google analytics)

Widespread Adoption

• All of this has lowered the barrier to entry for exploiting vulnerabilities

• There are large numbers of people with the means and motive to attack any system online

• Furthermore secure practices are often not followed

– See next slide

Many Systems Remain Vulnerable

• Remember the issues with Open SSL that surfaced in early 2014? – Despite widespread news reports, many systems continue to be vulnerable

• June 2014 survey of TLS vulnerabilities

Cloud Related Issues

• In many respects security in the cloud is not different from security for a traditional system

• Some threats are magnified, and some additional threats exit

• We’ll look at: – VM sprawl

– Insecure interfaces or API

– Malicious insiders

– Shared resources

VM Sprawl

• VM creations is quick and easy – It can be done in seconds without procuring hardware,

administrative knowledge, or securing permissions

• As a result it’s done often – Sometimes for transient needs

• Once created the VM is often forgotten about – It might still exist even if it is no longer doing any work

• Keeping track of the existing VMs is difficult to do – It requires different processes than tracking physical assets

• This results in something called VM Sprawl

Consequences of VM Sprawl

• VM Sprawl is bad for many reasons

• First, it imposes additional overhead on the overall solution

– The VM still costs money even if it is offline

• Second, it is less likely to be included in the normal maintenance efforts

– Updates and patches might not be applied

• As a result the VM can remain vulnerable

Insecure Interfaces or API

• IaaS and PaaS providers expose a set of API • These API are used by customers to:

– Provision – Manage – Orchestrate – Monitor – …

• The security of the cloud is dependent on the security of these API

• These API must be designed in a way to resist accidental and malicious attempts to circumvent policy

3rd Party API

• We not only need to trust the expertise and procedures of the cloud providers but 3rd party vendors as well

• Organizations often layer capability on top of the provided API in order to add value to the consumer e.g. – Deployment tools

– Monitoring aggregation tools

– Data management services

– …

• The security of these providers also needs to be trusted

How Does This Work?

User 3rd Party Service Cloud Provider

Malicious Insiders

• Malicious insiders are a known and significant threat to corporate security

– E.g. former and disgruntled employees

• When deploying your application on the cloud you need to worry about employees of the cloud provider as well

Shared Resources

Shared Resources

• When software running in a process within a VM can elevate privileges sufficiently they can “escape” the bounds of the VM

• This is called “guest to host VM escape”

• Once this happens the software is able to control all of the instances within that hypervisor

Hypervisor Vulnerabilities

• The most commonly used hypervisors have all been exploited

• Vulnerabilities continue to be discovered in all of the major hypervisor software

– Discovered by both the good guys and bad guys

• Do a Google search on VM Escape for the latest vulnerabilities …

Addressing Security Issues

• The strategies for dealing with security issues typically fall into one of three categories

– Secure coding practices

– Processes and policy

– Architectural approaches

Secure Coding Practices

• Looking at the source of the vulnerabilities it may seem that secure coding practices will solve the problem

• While this is true to some extent as we said these vulnerabilities exist in most commercially available software

• We must therefore assume that our software is to some extent insecure

• It’s also the case that we will miss issues

• Inevitably the software will have defects, will be used in a context other than what was intended, or will be used with software that it wasn’t intended to work with

Processes and Policy

• A large aspect of dealing with security includes processes and procedures

• The security of the system is impacted by things like: – Physical security

– IT policy governing computers on the network

– Updating and patching procedures

– Organizational structure and access policies

• Defining appropriate practices is a key component to security

Agenda





• Summary

Security Strategies

• Security strategies fall in one of several categories – Policy/process

– Secure coding practices

– Architectural

• We will now look at some architectural strategies

• The thing to keep in mind is that you cannot easily eliminate all vulnerabilities – Some of the approaches are aimed at minimizing vulnerabilities

– Some are aimed at reducing the impact if the vulnerabilities are exploited

Resisting Attacks

• Resisting attacks is analogous to securing the perimeter

• Strategies for resisting attacks include:

– Encryption

– Checking data integrity

– Limiting exposure

– Limiting access

Encryption

• Applied to data and communications can help maintain confidentiality

• Can be symmetric

– Both parties use the same key

• Or asymmetric

– Public/private key

Encryption

• What kind of attack would encryption protect against?

• What kind of attack would it not protect against?

• What kind of security concern would it address?

Data Integrity

• Encoding data with checksum or hash results can help ensure the data has not been tampered with

• This additional data can be encrypted along with or independently from the original data

Data Integrity

• Think about data integrity concerns in the context of some of the recent attacks

– Stuxnet

– Gauss

– …

• These techniques can be important for detecting an attack

– Additional techniques might be needed to recover

Limiting Exposure

• Attacks depend on exploiting weaknesses to gain access to data and services

• Limiting access to the attack surface limits risk*

• The following are approaches to limiting exposure

* Manadhata 2006

Client Data Storage

• Problem: many applications store data at potentially untrusted clients.

– These clients could tamper with the data

• Solution: this pattern uses encryption to store security-critical data client-side

Client Data Storage II

• Manual inspection of this data could reveal details of the application that could be used to compromise the site

Client Input Filters

• Problem: in many cases clients execute outside the control of the system developer.

– These clients can be tampered with to behave in an untrustworthy manner

• Solution: treat all data provided by clients as suspect

Client Input Filters II

• Perform (or re-execute) data validity checks on the server

• Exam headers and URLs for malicious code

• Text input should be checked for scripts

• Calculated fields should be re-computed on the server

• Considerations: – Should use a symmetric key as it’s less computationally expensive

– Storage of the key should not be stored in a file

Trusted Proxy

• Problem: it may be necessary to expose inadequately protected aspects of the system to untrusted users

• Solution: create a trusted proxy that acts as a buffer between the component and the users

Trusted Proxy II

• This proxy intercepts and filters all communication

• In that way it can compensate for the lack of protections

• Typically two options – Filter requests for bad input

– Recreate a new request with only the essential parts of the old request

Single Access Point

Problem: a system is more difficult to secure if it has multiple entry points

• With multiple entry points: – You may need to separately secure multiple applications

– You may have duplicate authentication logic to maintain

– Unix is an example with multiple entry points

– Different services can be set up on different machines

Single Access Point II

• The solution is to create a single point of entry

• A session is then created

• This allows global tracking of session state and authorization information

• There is a single “gateway” or “check point” through which user’s login is validated

Single Access Point III

• Which aspects of security does this pattern address?

• What are some of the implications of using this pattern?

Partitioned Application

• Problem: large complex applications often require root privileges in some portions of the application

– If these elements are compromised the entire system is at risk

• Solution: partition the large application into smaller elements each adhering to least privilege principle

Partitioned Application II

• This becomes more difficult to manage

• Additionally performance can suffer as interprocess communication increases

• Additional points of entry are introduced

– Even though the impact of being compromised is diminished

Password Propagation

• Problem: most applications manage user data under a single database account

– Thus if the single account is compromised all user data can be accessed

• Solution: the users password is required with each backend database request

Password Propagation II

• This is essentially an instance of application partitioning

• The front end will cache the password and provide it with each back end request

Limiting Access

• You can think of this as “securing the perimeter”

• This is a widely used approach of limiting access to data and services

• The following are examples of techniques for limiting access

Session

• Background: Systems need to keep track of user’s login status, level of authorization, and so forth

– The Singleton pattern is often used for this

– This pattern can be difficult to use when the system support concurrent logins

• The solution is to create a “session” object to hold these global variables

Session II

• This session object is accessible by all components of the application

• This facilitates having a common interface for accessing this information

– Easier to implement and maintain than having a number of variables passed around

Roles

• Background: when an application supports many types of users security becomes more complicated

– It can be difficult to track and maintain all of the things that every user has access to

• It eases implementation issues if a smaller number of “roles” are created

• Each role has a given set of rights

Roles II

• What kinds of security does this address?

• Implications?

Account Lockout

• Problem: there is an increased number of password guessing tools to compromise systems requiring user authentication

• Solution: lock the user account after some number of incorrect attempts

• How it works: – The system records each incorrect login attempt

– When a predetermined number of attempts is reached the account is locked

– Each time there is a correct login the account is reset

Account Lockout II

• Issues:

– Doesn’t address the situation where different user IDs are used

– Usability can be adversely affected

– Availability can be adversely affected

• Can facilitate denial of service

Detecting Attacks

• Detect Intrusion

• Detect Denial of Service

Minefield

• Problem: hackers are likely familiar with the vulnerabilities of various configurations

– Once they figure out your setup they’ll know how to get in

• Solution: change your setup to a non-standard configuration

Minefield II

• Even small changes can increase the effort enough to discourage hackers

• You can do things like:

– Alter file structure

– Rename common administrative commands

– Instrument commands to alert administrators

– Add booby traps that will recognize tampering

Secure Assertion

• Problem: the activities performed by a malicious intruder may look legitimate at the local level

– E.g. transferring money from an account

• Solution: create a framework for reporting specific activities that violate assertions

Secure Assertion II

• The application developer is in a position to determine activities that may be suspicious

– They can create assertions

• If the application is being developed in an environment that supports exceptions, assertion violations could be reported in a similar fashion

• The violations could be collected globally to provide additional insight on the current activities

Recovering From Attacks

• Availability tactics

– We will discuss these in a future class

• Auditing

– Keeps a trail of the users and their actions

– Helps to maintain a record of the attack

Network Address Blacklist

• Problem: all systems with an online presence are subject to attack

– Locking individual accounts doesn’t address systemic attacks

• Solution: block network addresses that are the source of attack

Network Address Blacklist II

• The server will monitor requests from clients

– Any suspicious requests will be logged

– If there are repeated suspicious requests the address is blocked

• One question is where to implement the check

– Network (e.g. firewall) or application

• Performance as list grows can be an issue

• Can still be subject to denial of service attack

Agenda





• Summary

So How Do We Decide?

• There are many options, which ones are required?

• What are the side effects of selecting these security mechanisms?

Fit for Purpose

• It is (hopefully) clear that each of these techniques addresses a different concern

• What concerns does your organization have?

– This depends on the business assets that need protection

– And the ways in which these assets could be compromised given the system

Threat Modeling

Threat Modeling and Analysis in a nutshell:

– Identify the business asset to protect

– Brainstorm the known threats to the system

– Rank the threats by decreasing risk

– Chose techniques to mitigate the threats

– Chose appropriate technologies from the identified techniques

Business Asset

• The reason for security is to protect some aspect of the business

• You need to identify those aspects of the business that need protection

• You also to determine what “protection” means

Brainstorm Threats

• Given a particular design what might happen to compromise the business asset?

• You should think about these from two perspectives

– Likelihood

– Impact

• At this point you don’t worry about if they need mitigation

Rank the Threats

• Based on the likelihood and the impact you can determine the “risk exposure”

– Look at risk management techniques

• Prioritize the risks according to the exposure

• Determine the threshold that require mitigation

Mitigation Techniques

• Look for generic patterns that will mitigate the risks

• Mitigate means lower the risk exposure to a tolerable level

– You lower the exposure by reducing the likelihood or reducing the impact

– A tolerable level means below the threshold defined previously

Choose Technologies

• Basically you need to map the generic pattern to some concrete solution

• This is where you factor in the costs

• Costs could come in terms of level of effort to implement

• Costs could also come in terms of tradeoffs

– You might need to iterate these steps

Consider Trade Offs

• Most of these mechanism adversely impact performance

– Blindly selecting these capabilities can bring the system to a standstill

• They also have an impact on the flexibility of the system

• Balancing concerns is key

References

• STRIDE: http://msdn2.microsoft.com/en-us/library/aa302419.aspx

• Hinton, Hondo, Hutchison: Security Patterns within a Service Oriented Architecture IBM 2005

• Hafiz, Johnson Security Patterns and their Classification Schemes

• Thomas Erl Service Oriented Architecture Chapters 4 and 11

• SEI/CERT OCTAVE: Operationally Critical Threat, Asset, and Vulnerability Evaluation: http://www.cert.org/octave

• Manadhata et al. Measuring the Attack Surfaces of Two FTP Daemons 2006

http://msdn2.microsoft.com/en-us/library/aa302419.aspx



http://www.cert.org/octave

Questions??