The Guerilla CISO

DDoS Vocabulary and Mathematics

rybolov — Fri, 26 Oct 2012 01:36:40 +0000

Some language and math that come in handy when you talk about or fight Distributed Denial of Service…

Distributed Denial of Service: an attack that uses a number of attacking nodes that overwhelm the target with network, web, or application traffic. DDoS implies 100 or more nodes attacking the same target, although just about everybody has their own threshold for what consitutes “distributed”.

Command and Control (C2): how the attackers get instructions to the attacking nodes. This could be automated in the case of a botnet (and probably what defines a botnet if you think about it too hard) or done manually as in the case of some booter scripts, or, as in the case of hacktivists, done with IRC, flyers, manifestos, and forums. Different C2 has different strengths and weaknesses.

Node: a unique IP address that is participating in a DDoS. Not to be confused with node.js. =)

Lethality: The lethality of a DDoS is a function of the number of attacking nodes times the average bandwidth per node with efficiency multipliers for how high in the technology stack that the attack goes (layer 3/4 versus 5-7) and if the nodes all attack at the same time (determined by the quality of the attacker’s command and control (C2) ). It really is a brute force numbers game for the most part.

Average Bandwidth:

Home users in US: 1-2 Mbps
Home users in South America, Africa, South Asia: .5 Mbps
Home users in South Korea, Japan: 5Mbps
Virtual Private Server: 100Mbps
Core Routers: 1000Mbps and up

Number of Nodes: divide the total bandwidth of attack traffic received by the average node bandwidth to determine how many attacking nodes there are. So, for example, a hacktivist army attacking a site and bringing 2Gbps of attack traffic has around 2,000-4,000 participants.

Recruitment: how fast the attackers (botnet via malware, hacktivists, homebrew botnet, etc) can add nodes to the attack. This could also be correlated with rates of infection for botnets consisting of home PC users, rates of exploits for servers, number of hacktivists joining in the campaign, etc.

Attrition: how fast the attackers lose nodes. This could be due to ISPs blocking node access due to detection of attack traffic or bandwidth caps, hacktivists headed off to work during the week, the end of a significant campaign, or the general lack of interest in the attack.

Rate of Growth or Decay of an Attack: total size of attacking nodes plus recruitment minus attrition.

Cute Bot Couple photo by Jenn and Tony Bot

Similar Posts:

The post DDoS Vocabulary and Mathematics first appeared on The Guerilla CISO.

DDoS and Elections

rybolov — Thu, 10 May 2012 11:42:20 +0000

I’ve noticed a trend over the past 6 months: DDoS traffic associated with elections. A quick sampling of news will show the following:

http://www.opendemocracy.net/od-russia/irina-borogan-andrei-soldatov/kremlin-and-hackers-partners-in-crime <-Russia
http://www.theregister.co.uk/2012/03/26/hong_kong_vote_hack/ <-Hong Kong
http://www.theregister.co.uk/2011/12/07/korean_election_ddos_row/ <-Korea
http://www.cbc.ca/news/politics/story/2012/03/27/pol-ndp-voting-disruption-deliberate.html <-Canada (rybolov: yikes!)
http://www.csoonline.com/article/700523/ddos-attackers-target-russian-election-webcams <-Russia again

Last week it picked up again with the re-inauguration of Vladimir Putin.

And then yesterday, Ustream and their awesome response: which, in the Rybolov-paraphrased version read something like: “We shall go on to the end. We shall fight in France, we shall fight on the Interblagosphere, we shall fight with growing confidence and growing strength in our blocking capabilities, we shall defend our videostreams, whatever the cost may be. We shall fight on the routers, we shall fight on the load balancers, we shall fight in the applications and in the databases, we shall fight by building our own Russian subsite; we shall never surrender!!!!1111” (Ref)

Afghanistan Presidential Elections 2004 photo by rybolov.

So why all this political activity? A couple of reasons that I can point to:

Elections are a point-in-time. It’s critical for one day. Anything that has a short window of time is a good DDoS target.
DDoS is easy to do. Especially for the Russians. Some of them already have big botnets they’re using for other things.
Other DDoS campaigns. Chaotic Actors (Anonymous and their offshoots and factions) have demonstrated that DDoS has at a minimum PR value and at the maximum financial and political value.
Campaign sites are usually put up very quickly. They don’t have much supporting infrastructure and full/paid/professional staffing.
Elections are IRL Flash Mobs. Traffic to a campaign site increases slowly at first then exponentially the closer you get to the day of the election. This stresses what infrastructure is in place and design ideas that seemed good at the time but that don’t scale with the increased load.

So is this the future of political campaigns? I definitely think it is. Just like any other type of web traffic, as soon as somebody figures out how to use the technology for their benefit (information sharing => eCommerce => online banking => political fundraising), a generation later somebody else figures out how to deny that benefit.

How to combat election DDoS:

Have a plan. You know that the site is going to get flooded the week of the election. Prepare accordingly. *ahem* Expect them.
Tune applications and do caching at the database, application, webserver, load balancer, content delivery network, etc.
Throw out the dynamic site. On election day, people just want to know a handful of things. Put those on a static version of the site and switch to that. Even if you have to publish by hand every 30 minutes, it’s better than taking a huge outage.
Manage the non-web traffic. SYN and UDP floods have been around for years and years and still work in some cases. For these attacks, you need lots of bandwidth and something that does blocking: these point to a service provider that offers DDoS protection.

It’s going to be an interesting November.Similar Posts:

The post DDoS and Elections first appeared on The Guerilla CISO.

FedRAMP: It’s Here but Not Yet Here

rybolov — Mon, 12 Dec 2011 15:38:28 +0000

Contrary to what you might hear this week in the trade press, FedRAMP is not fully unveiled although there was some much-awaited progress. There was a memo that came out from the administration (PDF caveat). Basically what it does is lay down the authority and responsibility for the Program Management Office and set some timelines. This is good, and we needed it a year and a half ago.

However, people need to stop talking about how FedRAMP has solved all their problems because the entire program isn’t here yet. Until you have a process document and a catalog of controls to evaluate, you don’t know how the program is going to help or hinder you, so all the press about it is speculation.Similar Posts:

The post FedRAMP: It’s Here but Not Yet Here first appeared on The Guerilla CISO.

The “Off The Record” Track

rybolov — Mon, 21 Nov 2011 18:58:30 +0000

So while I was at some conferences over the past couple of months, I had an awesome idea while sitting in a panel about data breaches, especially notification. While streaming conferences is pretty awesome for most content, I keep thinking that we need that as an industry we need the exact opposite: a track of the conference that is completely off-the-record.

Here in DC when we do smaller training sessions, we invoke the Chatham House Rule. That is, the discussion is for non-attribution. There are several reasons behind this:

You don’t have to worry (too much, anyway) about vendors in attendance selling you something
It won’t end up in the press
It gets real information to people instead of things that are “fit for public consumption”

My local area has a hackers association (No linkie, if you have minimal skill you can find it) that meets to talk about mostly technical stuff and what folks are working on. I find that more and more often when I do a talk there I do it “Off the Record” for a wide variety of reasons:

I don’t want the attackers to get more effective
I have half-baked ideas where I want/need feedback on if they are completely off-base
The subject matter is in a legal gray-area and I’m not a lawyer
I talk “on the record” all day every day about the same things
I can “test-drive” presentation material to see how it works
I can show nuts and bolts

So, the point of all this is that maybe we need to start having more frank discussions about what the bad guys are doing “in the wild” if we want to stop them, and that involves talking with peers from other companies inside the same industry to see what they are getting hit with.

Chatham House Rule photo by markhillary.

Similar Posts:

The post The “Off The Record” Track first appeared on The Guerilla CISO.

DHS is Looking for a CISO

rybolov — Fri, 04 Nov 2011 20:38:02 +0000

Job announcement is here. Share with anybody you think can do it.Similar Posts:

The post DHS is Looking for a CISO first appeared on The Guerilla CISO.

#RefRef the Vaporware DoS Tool

rybolov — Fri, 23 Sep 2011 18:53:59 +0000

Ah yes, you now know how I spend my Saturday mornings lately.

Similar Posts:

The post #RefRef the Vaporware DoS Tool first appeared on The Guerilla CISO.

A Little Story About a Tool Named #RefRef

rybolov — Fri, 23 Sep 2011 18:53:34 +0000

Let me tell you a little story.

So September 17th was Constitution Day and was celebrated by protestors in most major cities across the US with a sizable percentage of folks on Wall Street in NYC. In conjunction with this protest, a new Denial-of-Service tool, #RefRef, was supposed to be released. It supposedly used some SQL Injection techniques to put a file (originally listed as a JavaScript but Java is more believable) on application or database servers that then created massive amounts of OS load, thereby crippling the server. The press coverage of the tool does have the quote of the year: ““Imagine giving a large beast a simple carrot, [and then] watching the best choke itself to death.” Seriously?

Then came the 17th. I checked the site, whoa, there is some perl code there. Then I read it and it sounded nothing like the tool as described. Rumor around the Intertubes was that #RefRef was/is a hoax and that the people responsible were collecting donations for R&D.

This is what we actually have for the tool that was released on the RefRef site does:

GET /%20and%20(select+benchmark(99999999999,0x70726f62616e646f70726f62616e646f70726f62616e646f)) HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.1.12) Gecko/20080201Firefox/2.0.0.12

The way this works is that it requests a large amount of benchmark queries against the database. This is very similar to SQL Injection in that the request contains database commands which are then passed by the application server to the database. In this case, the SQL command is “benchmark” which executes the query multiple times to build test performance of the query. As you would guess, it generates a ton of database server load. However, it’s only applicable to MySQL.Similar Posts:

The post A Little Story About a Tool Named #RefRef first appeared on The Guerilla CISO.

Training the Apache Killers

rybolov — Fri, 02 Sep 2011 16:50:36 +0000

Here at IKANHAZFIZMA, we’re training the next generation of Apache webserver Denial-of-Service gurus. It involves punching bags, some nomz for the troops, and lots of requests for kibble.

Similar Posts:

The post Training the Apache Killers first appeared on The Guerilla CISO.

Apache Killer Effects on Target

rybolov — Tue, 30 Aug 2011 13:49:14 +0000

Oh noes, the web is broken. Again. This time it’s the Apache Killer. This inspired a little ditty from @CSOAndy based on a Talking Heads tune:

I can’t seem 2 handle the ranges

I’m forked & memlocked & I Can’t spawn

I can’t sleep ’cause my net’s afire

Don’t spawn me I’m a dead server

Apache Killer Qu’est-ce que c’est

da da da da da da da da da dos me now

Fork fork fork fork fork fork fork away

Going back to my blog post last week about Slow Denial-of-Service, let’s look at what Apache Killer is. Yes kan haz packet capture for packet monkeys (caveat: 2.3MB worth of packets)

Home on the Range

The Apache vulnerability uses a HTTP header called “Range”. Range is used for partial downloads, these are common in streaming video, in the “resume” feature for large downloads, and in some PDF/eDocument readers (Acrobat Reader does this in a big way). That way, the client (which is almost never a web browser in this case) can request a specific byte range or multiple byte ranges of an object instead of requesting “the whole enchilada”. This is actually a good thing because it reduces the amount of traffic coming from a webserver, that’s why it’s part of the HTTP spec. However, the spec is broken in some ways:

It has no upper limit on the number of ranges in a request.
It has no way to specify that a webserver is only servicing a specific number of ranges (maybe with a 416 response code).
The spec allows overlapping ranges.

In the interests of science, I’ll provide a sample of Range request Apache combined logs so you can see how these work in the wild, have a look here and the command used to make this monstrosity was this: zcat /var/log/apache2/www.guerilla-ciso.com.access.log.*.gz | awk ‘($9 ~ /206/)’ | tail -n 500 > 206traffic.txt

Apache Killer

Now for what Apache Killer does. You can go check out the code at the listing on the Full Disclosure Mailing List. Basic steps for this tool:

Execute a loop to stitch together a Range header with multiple overlapping ranges
Stitch the Range into a HTTP request
Send the HTTP request via a net socket

The request looks like this, note that there are some logic errors in how the Range is stitched together, some of the ranges have start values that are after the end value if the start < 5 and the first range doesn’t have an end value:

HEAD / HTTP/1.1
Host: localhost
Range:bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,5-10,5-11,5-1293,5-1294,5-1295,5-1296,5-1297,5-1298,5-1299
Accept-Encoding: gzip
Connection: close

What The Apache Sees

So this brings us to the effect on target. The normal behavior for a Range request is to do something like the following:

Load the object off disk (or from an application handler like php or mod_perl)
Return a 206 Partial Content
Respond with multiple objects to satisfy the ranges that were requested

In the case of Apache Killer, Apache responds in the following way:

HTTP/1.1 206 Partial Content
Date: Tue, 30 Aug 2011 01:00:28 GMT
Server: Apache/2.2.17 (Ubuntu)
Last-Modified: Tue, 30 Aug 2011 00:18:51 GMT
ETag: “c09c8-0-4abadf4c57e50”
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 123040
Connection: close
Content-Type: multipart/byteranges; boundary=4abae89a423c2199d

Of course, in trying to satisfy the Range request, apache loads the object into memory but then there is a huge amount of ranges and because the ranges are overlapping, Apache has to load a new version of the object to satisfy each byte range. This results in a memory fork. It also keeps that server process busy, resulting in a process fork attack like a Slow DoS would also do.

The Apache access log (on a Debian derivative it’s in /var/log/apache2/access.log )

127.0.0.1 – – [29/Aug/2011:18:00:34 -0700] “HEAD / HTTP/1.1” 206 353 “-” “-”
127.0.0.1 – – [29/Aug/2011:18:00:34 -0700] “HEAD / HTTP/1.1” 206 353 “-” “-”
127.0.0.1 – – [29/Aug/2011:18:00:34 -0700] “HEAD / HTTP/1.1” 206 354 “-” “-”
127.0.0.1 – – [29/Aug/2011:18:00:34 -0700] “HEAD / HTTP/1.1” 206 354 “-” “-”
127.0.0.1 – – [29/Aug/2011:18:00:34 -0700] “HEAD / HTTP/1.1” 206 353 “-” “-”
127.0.0.1 – – [29/Aug/2011:18:00:34 -0700] “HEAD / HTTP/1.1” 206 354 “-” “-”

Note that we’re giving a http response code of 206 (which is good) but there is no referrer or User-Agent. Let’s filter that stuff out of a full referrer log with some simple shell scripting (this site has an awesome guide to parsing apache logs):

tail -n 500 access.log | awk ‘($9 ~ /206/ )’

which says this:

Grab the last 500 log lines.

Find everything that is a 206 response code.

For me, the output is 499 copies of the log lines I showed above because it’s a test VM with no real traffic. On a production server, you might have to use the entire access log (not just the last 500 lines) to get a larger sample of traffic.

I’ll also introduce a new fun thing: Apache mod_status. On a Debian-ish box, you have the command “apachectl status” which just does a simple request from the webserver asking for /server-status.

root@ubuntu:/var/log/apache2# apachectl status
Apache Server Status for localhost

Server Version: Apache/2.2.17 (Ubuntu)
Server Built: Feb 22 2011 18:34:09
__________________________________________________________________

Current Time: Monday, 29-Aug-2011 20:49:57 PDT
Restart Time: Monday, 29-Aug-2011 16:21:02 PDT
Parent Server Generation: 0
Server uptime: 4 hours 28 minutes 54 seconds
Total accesses: 5996 – Total Traffic: 637.5 MB
CPU Usage: u107.39 s2.28 cu0 cs0 – .68% CPU load
.372 requests/sec – 40.5 kB/second – 108.9 kB/request
1 requests currently being processed, 74 idle workers

_________________W_______…………………………………
……………………………………………………….
_________________________…………………………………
_________________________…………………………………
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….

Scoreboard Key:
“_” Waiting for Connection, “S” Starting up, “R” Reading Request,
“W” Sending Reply, “K” Keepalive (read), “D” DNS Lookup,
“C” Closing connection, “L” Logging, “G” Gracefully finishing,
“I” Idle cleanup of worker, “.” Open slot with no current process

The interesting part for me is the server process status codes. In this case, I have one server (W)riting a reply (actually, servicing the status request since this is on a VM with no live traffic). During an attack, all of the server process’s time is spent writing a response:

root@ubuntu:/var/log/apache2# apachectl status
Apache Server Status for localhost

Server Version: Apache/2.2.17 (Ubuntu)
Server Built: Feb 22 2011 18:34:09
__________________________________________________________________

Current Time: Monday, 29-Aug-2011 20:53:48 PDT
Restart Time: Monday, 29-Aug-2011 16:21:02 PDT
Parent Server Generation: 0
Server uptime: 4 hours 32 minutes 45 seconds
Total accesses: 7064 – Total Traffic: 760.8 MB
CPU Usage: u128.49 s2.65 cu0 cs0 – .801% CPU load
.432 requests/sec – 47.6 kB/second – 110.3 kB/request
51 requests currently being processed, 24 idle workers

___WW__WW__W_WW__W___WWW_…………………………………
……………………………………………………….
__WWWWW_W____WWW__WW_WWWW…………………………………
WWWWWWWWWWWWWWWWWWWWWWWWW…………………………………
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….
……………………………………………………….

Now for a Slow HTTP DoS, you get some of the memory consumption and the Apache process forking out of control, but all of the server processes are stuck doing (R)ead operations (IE, reading a request from clients) if you can even get a response (the mod_status query is also an HTTP request which means you’re doing in-band management during a DoS attack). This is interesting to me as an item that helps me differentiate the attacks from a troubleshooting standpoint.

Detecting and Mitigating

This is always the fun part. Detection should be something like the following, all of these I’ve given examples in this blog post for you:

Apache forks new processes. A simple “ps aux | grep apache | wc -l” compared with “grep MaxClients /etc/apache2/apache2.conf” should suffice.
Apache uses up tons of memory. You can detect this using top, htop, or even ps.
Apache mod_status shows an excess of server daemons performing write options.
Apache combined access logs show an excess of 206 response code with no referrer and no User-Agent.

As far as mitigation, the Apache Project put out an awesome post on this, something I can’t really top on the server itself.Similar Posts:

The post Apache Killer Effects on Target first appeared on The Guerilla CISO.

Noms and IKANHAZFIZMA

rybolov — Fri, 26 Aug 2011 16:01:18 +0000

Kickin’ it old-school with some kitteh overflows

Similar Posts:

The post Noms and IKANHAZFIZMA first appeared on The Guerilla CISO.

The Rise of the Slow Denial of Service

rybolov — Tue, 23 Aug 2011 13:48:32 +0000

Usually when you think about Denial of Service attacks nowadays, most people think up images of the Anonymous kids running their copy of LOIC in a hivemind or Russian Gangsters building a botnet to run an online protection racket. Now there is a new-ish type of attack technique floating around which I believe will become more important over the next year or two: the slow http attacks.

Refs:

How Slow DOS Works

Webservers run an interesting version of process management. When you start an Apache server, it starts a master process that spawns a number of listener processes (or threads) as defined by StartServers (5-10 is a good starting number). Each listener serves a number of requests, defined by MaxRequestsPerChild (1000 is a good number here), and then dies to be replaced by another process/thread by the master server. This is done so that if there are any applications that leak memory, they won’t hang. As more requests are received, more processes/threads are spawned up to the MaxClients setting. MaxClients is designed to throttle the number of processes so that Apache doesn’t forkbomb and the OS become unmanageable because it’s thrashing to swap. There are also some rules for weaning off idle processes but those are immaterial to what we’re trying to do today.

Go read my previous post on Apache tuning and stress testing for the background on server pool management.

What happens in a slow DOS is that the attack tools sends an HTTP request that never finishes. As a result, each listener process never finishes its quota of MaxRequestsPerChild so that it can die. By sending a small amount of never-complete requests, Apache gladly spawns new processes/threads up to MaxClients at which point it fails to answer requests and the site is DOS’ed. The higher the rate of listener process turnover, the faster the server stops answering requests. For a poorly tuned webserver configuration with MaxClients set too high, the server starts thrashing to swap before it hits MaxClients and to top it off, the server is unresponsive even to ssh connections and needs a hard boot.

The beauty of this is that the theoretical minimum number of requests to make a server hang for a well-tuned Apache is equal to MaxClients. This attack can also take out web boundary devices: reverse proxies, Web Application Firewalls, Load Balancers, Content Switches, and anything else that receives HTTP(S).

Post photo by Salim Virji.

Advantages to Slow DOS Attacks

There are a couple of reasons why slow DOS tools are getting research and development this year and I see them growing in popularity.

Speed and Simplicity: Slow DOS attacks are quick to take down a server. One attacker can take down a website without trying to build a botnet or cooordinate attack times and targets with 3000 college students and young professionals.
TOR: With volume-based attacks like the Low Orbit Ion Cannon, it doesn’t make sense to route attack traffic through TOR. TOR adds latency, throttles the amount of requests that the attacker can send, and might eventually fail before the target’s network does. Using TOR keeps the defender from tracking you back to your real location.
Server Logging: Because the request is never completed, most servers don’t make a log. This makes it very hard to detect or troubleshoot which means it takes longer to mitigate. I’m interested in exceptions if you know specifics on which webserver/tool combinations make webtraffic logs.
IDS Evasion: Most DOS tools are volume-based attack. There are IDS rules to detect these: usually by counting the number of TCP SYN traffic coming from each IP address in a particular span of time and flagging the traffic when a threshold is exceeded. By using a slow DOS tool that sends requests via SSL, IDS has no idea that you’re sending it slow DOS traffic.
Stay out of the “Crowbar Hotel”: Use the Ion Cannon, make logs on the target system, go to jail. Use slow DOS with TOR and SSL, leave less traces, avoid having friends that will trade you for a pack of cigarettes.

Defenses

This part is fun, and by that I mean “it sucks”. There are some things that help, but there isn’t a single solution that makes the problem go away.

Know how to detect it. This is the hard one. What you’re looking for is Apache spawned out to MaxClients but not logging a comparative volume of traffic. IE, the servers are hung up waiting for that one last request to finish and shucking all other requests.

“ps aux | grep apache2 | grep start | wc -l” is equal to MaxClients +2.
Your webserver isn’t logging the normal amount of requests. Use some grep-foo and “wc -l” to compare traffic from: a month ago, a day ago, an hour ago, and the last 5 minutes.

Disable POST as a method if you don’t need it. Some of the more advanced techniques rely on the fact that POST can contain more headers and more body data.
Use an astronomically high number of servers. If your server processes can timeout and respawn faster than the slow DOS can hang them, you win. If you had maybe 3000 servers, you wouldn’t have to worry about this. Don’t have 3000 servers, I might have some you could use.
Set a lower connection timeout. Something like 15-30 seconds will keep Apache humming along.
Limit the request size. 1500 bytes is pretty small, 3K is a pretty good value to set. Note that this needs testing, it will break some things.
Block TOR exit nodes before the traffic reaches your webservers (IE, at layer 3/4). TOR has a list of these.

Similar Posts:

The post The Rise of the Slow Denial of Service first appeared on The Guerilla CISO.

DDoS Planning: Business Continuity with a Twist

rybolov — Wed, 17 Aug 2011 14:06:00 +0000

So since I’ve semi-officially been granted the title of “The DDoS Kid” after some of the incident response, analysis, and talks that I’ve done, I’m starting to get asked a lot about how much the average DDoS costs the targeted organization. I have some ideas on this, but the simplest way is to recycle Business Continuity/Disaster Recovery figures but with some small twists.

Scoping:

Plan on a 4-day attack. A typical attack duration is 2-7 days.
Consider an attack on the “main” (www) site and anything else that makes money (shopping cart, product pages)

Direct:

Downtime: one day’s worth of downtime for both peak times (for most eCommerce sites, that’s Thanksgiving to January 5th) and low-traffic times x (attack duration).
Bandwidth: For services that charge by the bit or CPU cycle such as cloud computing or some ISP services, the direct cost of the usage bursting. The cost per bit/cpu/$foo is available from the service provider, multiply your average rate for peak times by 1000 (small attack) or 10000 (large attack) x (attack duration) worth of usage. This is the only big difference in cost from BCP/DR data.
Mitigation Services: Figure $5K to $10K for a DDoS mitigation service x (duration of attack).

Indirect:

Increased callcenter load: A percentage (10% as a starting guess) of user calls to the callcenter x (average dollar cost per call) x (attack duration).
Increased physical “storefront” visits: A percentage (10%) of users now have to go to a physical location x (attack duration).
Customer churn: customer loss due to frustration. Figure 2-4% customer loss x (attack duration).

Brand damage, these vary from industry to industry and attack to attack:

Increased marketing budget: Percentage increase in marketing budget. Possible starting value is 5%.
Increased customer retention costs: Percentage increase in customer retention costs. Possible starting value is 10%.

Note that it’s reasonably easy to create example costs for small, medium, and large attacks and do planning around a medium-sized attack.

However we recycle BCP/DR figures for an outage, mitigation of the attack is different:

For high-volume attacks, you will need to rely on service providers for mitigation simply because of their capacity.
Fail-over to a secondary site means that you now have two sites that are overwhelmed.
Restoration of service after the attack is more like recovering from a hacking attack than resuming service at the primary datacenter.

Similar Posts:

The post DDoS Planning: Business Continuity with a Twist first appeared on The Guerilla CISO.

Realistic NSTIC

rybolov — Wed, 10 Aug 2011 13:32:20 +0000

OK, it’s been out a couple of months now with the usual “ZOMG it’s RealID all over again” worry-mongers raising their heads.

So we’re going to go through what NSTIC is and isn’t and some “colorful” (or “off-color” depending on your opinion) use cases for how I would (hypothetically, of course) use an Identity Provider under NSTIC.

The Future Looks Oddly Like the Past

There are already identity providers out there doing part of NSTIC: Google Authenticator, Microsoft Passport, FaceBook Connect, even OpenID fits into part of the ecosystem. My first reaction after reading the NSTIC plan was that the Government was letting the pioneers in the online identity space take all the arrows and then swoop in to save the day with a standardized plan for the providers to do what they’ve been doing all along and to give them some compatibility. I was partially right, NSTIC is the Government looking at what already exists out in the market and helping to grow those capabilities by providing some support as far as standardizations and community management. And that’s the plan all along, but it makes sense: would you rather have experts build the basic system and then have the Government adopt the core pieces as the technology standard or would you like to have the Government clean-room a standard and a certification scheme and push it out there for people to use?

Not RealID Not RealID Not RealID

Many people think that NSTIC is RealID by another name. Aaron Titus did a pretty good job at debunking some of these hasty conclusions. The interesting thing about NSTIC for me is that the users can pick which identity or persona that they use for a particular use. In that sense, it actually gives the public a better set of tools for determining how they are represented online and ways to keep these personas separate. For those of you who haven’t seen some of the organizations that were consulted on NSTIC, their numbers include the EFF and the Center for Democracy and Technology (BTW, donate some money to both of them, please). A primary goal of NSTIC is to help website owners verify that their users are who they say they are and yet give users a set of privacy controls.

Stick in the Mud photo by jurvetson.

Now on to the use cases, I hope you like them:

I have a computer at home. I go to many websites where I have my public persona, Rybolov the Hero, the Defender of all Things Good and Just. That’s the identity that I use to log into my official FaceBook account, use teh Twitters, log into LinkedIn–basically any social networking and blog stuff where I want people to think I’m a good guy.

Then I use a separate, non-publicized NSTIC identity to do all of my online banking. That way, if somebody manages to “gank” one of my social networking accounts, they don’t get any money from me. If I want to get really paranoid, I can use a separate NSTIC ID for each account.

At night, I go creeping around trolling on the Intertubes. Because I don’t want my “Dudley Do-Right” persona to be sullied by my dark, emoting, impish underbelly or to get an identity “pwned” that gives access to my bank accounts, I use the “Rybolov the Troll” NSTIC ID. Or hey, I go without using a NSTIC ID at all. Or I use an identity from an identity provider in a region *cough Europe cough* that has stronger privacy regulations and is a couple of jurisdiction hops away but is still compatible with NSTIC-enabled sites because of standards.

Keys to Success for NSTIC:

Internet users have a choice: You pick how you present yourself to the site.

Website owners have a choice: You pick the NSTIC ID providers that you support.

Standards: NIST just formalizes and adopts the existing standards so that they’re not controlled by one party. They use the word “ecosystem” in the NSTIC description a lot for a reason.Similar Posts:

The post Realistic NSTIC first appeared on The Guerilla CISO.

Clouds, FISMA, and the Lawyers

rybolov — Tue, 26 Apr 2011 16:28:12 +0000

Interesting blog post on Microsoft’s TechNet, but the real gem is the case filing and summary from the DoJ (usual .pdf caveat applies). Basically the Reader’s Digest Condensed Version is that the Department of Interior awarded a cloud services contract to Microsoft for email. The award was protested by Google for a wide variety of reasons, you can go read the full thing for all the whinging.

But this is the interesting thing to me even though it’s mostly tangential to the award protest:

Google has an ATO under SP 800-37 from GSA for its Google Apps Premiere.
Google represents Google Apps for Government as having an ATO which, even though 99% of the security controls could be the same, is inaccurate as presented.
DOI rejected Google’s cloud because it had state and local (sidenote: does this include tribes?) tenants which might not have the same level of “security astuteness” as DOI. Basically what they’re saying here is that if one of the tenants on Google’s cloud doesn’t know how to secure their data, it affects all the tenants.

So this is where I start thinking. I thunk until my thinker was sore, and these are the conclusions I came to:

There is no such thing as “FISMA Certification”, there is a risk acceptance process for each cloud tenant. Cloud providers make assertions of what common controls that they have built across all
Most people don’t understand what FISMA really means. This is no shocker.
For the purposes of this award protest, the security bits do not matter because
This could all be solved in the wonk way by Google getting an ATO on their entire infrastructure and then no matter what product offerings they add on top of it, they just have to roll it into the “Master ATO”.
Even if the cloud infrastructure has an ATO, you still have to authorize the implementation on top of it given the types of data and the implementation details of your particular slice of that cloud.

And then there’s the “back story” consisting of the Cobell case and how Interior was disconnected from the Internet several times and for several years. The Rybolov interpretation is that if Google’s government cloud potentially has tribes as a tenant, it increases the risk (both data security and just plain politically) to Interior beyond what they are willing to accept.

Obligatory Cloud photo by jonicdao.

Similar Posts:

The post Clouds, FISMA, and the Lawyers first appeared on The Guerilla CISO.

LOLCATS and NSTIC

rybolov — Thu, 14 Apr 2011 13:16:04 +0000

Ref: NSTIC
Ref: On the Internet…

Similar Posts:

The post LOLCATS and NSTIC first appeared on The Guerilla CISO.

Some Comments on SP 800-39

rybolov — Wed, 06 Apr 2011 18:37:51 +0000

You should have seen Special Publication 800-39 (PDF file, also check out more info on Fismapedia.org) out by now. Dan Philpott and I just taught a class on understanding the document and how it affects security managers out them doing their job on a daily basis. While the information is still fresh in my head, I thought I would jot down some notes that might help everybody else.

The Good:

NIST is doing some good stuff here trying to get IT Security and Information Assurance out of the “It’s the CISO’s problem, I have effectively outsourced any responsibility through the org chart” and into more of what DoD calls “mission assurance”. IE, how do we go from point-in-time vulnerabilities (ie, things that can be scored with CVSS or tested through Security Test and Evaluation) to briefing executives on what the risk is to their organization (Department, Agency, or even business) coming from IT security problems. It lays out an organization-wide risk management process and a framework (layer cakes within layer cakes) to share information up and down the organizational stack. This is very good, and getting the mission/business/data/program owners to recognize their responsibilities is an awesome thing.

The Bad:

SP 800-39 is good in philosophy and a general theme of taking ownership of risk by the non-IT “business owners”, when it comes to specifics, it raises more questions than it answers. For instance, it defines a function known as the Risk Executive. As practiced today by people who “get stuff done”, the Risk Executive is like a board of the Business Unit owners (possibly as the Authorizing Officials), the CISO, and maybe a Chief Risk Officer or other senior executives. But without the context and asking around to find out what people are doing to get executive buy-in, the Risk Executive seems fairly non-sequitor. There are other things like that, but I think the best summary is “Wow, this is great, now how do I take this guidance and execute a plan based on it?”

The Ugly:

I have a pretty simple yardstick for evaluating any kind of standard or guideline: will this be something that my auditor will understand and will it help them help me? With 800-39, I think that it is written abstractly and that most auditor-folk would have a hard time translating that into something that they could audit for. This is both a blessing and a curse, and the huge recommendation that I have is that you brief your auditor beforehand on what 800-39 means to them and how you’re going to incorporate the guidance.Similar Posts:

The post Some Comments on SP 800-39 first appeared on The Guerilla CISO.

Micro Digital Signatures Howto

rybolov — Tue, 22 Feb 2011 14:56:11 +0000

With RSA wrapping up, I figured I would do something fun with Alice, Bob, and crypto. There is a need for small digital signatures (Micro Digital Signatures/”MicroDigiSigs” if I can be as bold as to think I can start a nerdy meme) and tools to support them over small message spaces such as The Twitters, SMS/Text Messaging, barcodes, jabber/xmpp, and probably tons of other things I haven’t even thought of.

Elliptic Curve Cryptography (ECC) provides a solution because of some inherent traits in the algorithms:

Speed to compute
Low processor load
Small keys
Small signatures

Some general-type info to know before we go further with this:

OpenSSL 1.00 supports ECC functions. This is teh awesome, thank you OpenSSL peoples.
You can check out the OpenSSL HOWTO, I derived a ton of info from this resource http://www.madboa.com/geek/openssl/
Issues with ECC support in OpenSSL:
- ECC is poorly documented in OpenSSL. Pls fix kthanx.
- Some targets are missing from OpenSSL (ECC Digital Signature Algorithm signatures with SHA-256).

Now on to the step-by-step process. Feel free to shoot holes in this, I’m sure there are tons of other ways to do things.

Show all the available curves:
rybolov@ryzhe:~$ openssl ecparam -list_curves
secp112r1 : SECG/WTLS curve over a 112 bit prime field
secp112r2 : SECG curve over a 112 bit prime field
secp128r1 : SECG curve over a 128 bit prime field
secp128r2 : SECG curve over a 128 bit prime field
secp160k1 : SECG curve over a 160 bit prime field
secp160r1 : SECG curve over a 160 bit prime field
secp160r2 : SECG/WTLS curve over a 160 bit prime field
secp192k1 : SECG curve over a 192 bit prime field
secp224k1 : SECG curve over a 224 bit prime field
secp224r1 : NIST/SECG curve over a 224 bit prime field
secp256k1 : SECG curve over a 256 bit prime field
secp384r1 : NIST/SECG curve over a 384 bit prime field
secp521r1 : NIST/SECG curve over a 521 bit prime field
prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field
prime192v2: X9.62 curve over a 192 bit prime field
prime192v3: X9.62 curve over a 192 bit prime field
prime239v1: X9.62 curve over a 239 bit prime field
prime239v2: X9.62 curve over a 239 bit prime field
prime239v3: X9.62 curve over a 239 bit prime field
prime256v1: X9.62/SECG curve over a 256 bit prime field
sect113r1 : SECG curve over a 113 bit binary field
sect113r2 : SECG curve over a 113 bit binary field
sect131r1 : SECG/WTLS curve over a 131 bit binary field
sect131r2 : SECG curve over a 131 bit binary field
sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field
sect163r1 : SECG curve over a 163 bit binary field
sect163r2 : NIST/SECG curve over a 163 bit binary field
sect193r1 : SECG curve over a 193 bit binary field
sect193r2 : SECG curve over a 193 bit binary field
sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field
sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field
sect239k1 : SECG curve over a 239 bit binary field
sect283k1 : NIST/SECG curve over a 283 bit binary field
sect283r1 : NIST/SECG curve over a 283 bit binary field
sect409k1 : NIST/SECG curve over a 409 bit binary field
sect409r1 : NIST/SECG curve over a 409 bit binary field
sect571k1 : NIST/SECG curve over a 571 bit binary field
sect571r1 : NIST/SECG curve over a 571 bit binary field
c2pnb163v1: X9.62 curve over a 163 bit binary field
c2pnb163v2: X9.62 curve over a 163 bit binary field
c2pnb163v3: X9.62 curve over a 163 bit binary field
c2pnb176v1: X9.62 curve over a 176 bit binary field
c2tnb191v1: X9.62 curve over a 191 bit binary field
c2tnb191v2: X9.62 curve over a 191 bit binary field
c2tnb191v3: X9.62 curve over a 191 bit binary field
c2pnb208w1: X9.62 curve over a 208 bit binary field
c2tnb239v1: X9.62 curve over a 239 bit binary field
c2tnb239v2: X9.62 curve over a 239 bit binary field
c2tnb239v3: X9.62 curve over a 239 bit binary field
c2pnb272w1: X9.62 curve over a 272 bit binary field
c2pnb304w1: X9.62 curve over a 304 bit binary field
c2tnb359v1: X9.62 curve over a 359 bit binary field
c2pnb368w1: X9.62 curve over a 368 bit binary field
c2tnb431r1: X9.62 curve over a 431 bit binary field
wap-wsg-idm-ecid-wtls1: WTLS curve over a 113 bit binary field
wap-wsg-idm-ecid-wtls3: NIST/SECG/WTLS curve over a 163 bit binary field
wap-wsg-idm-ecid-wtls4: SECG curve over a 113 bit binary field
wap-wsg-idm-ecid-wtls5: X9.62 curve over a 163 bit binary field
wap-wsg-idm-ecid-wtls6: SECG/WTLS curve over a 112 bit prime field
wap-wsg-idm-ecid-wtls7: SECG/WTLS curve over a 160 bit prime field
wap-wsg-idm-ecid-wtls8: WTLS curve over a 112 bit prime field
wap-wsg-idm-ecid-wtls9: WTLS curve over a 160 bit prime field
wap-wsg-idm-ecid-wtls10: NIST/SECG/WTLS curve over a 233 bit binary field
wap-wsg-idm-ecid-wtls11: NIST/SECG/WTLS curve over a 233 bit binary field
wap-wsg-idm-ecid-wtls12: WTLS curvs over a 224 bit prime field
Oakley-EC2N-3:
IPSec/IKE/Oakley curve #3 over a 155 bit binary field.
Not suitable for ECDSA.
Questionable extension field!
Oakley-EC2N-4:
IPSec/IKE/Oakley curve #4 over a 185 bit binary field.
Not suitable for ECDSA.
Questionable extension field!

ECC keys are specific to curves. Make a key for secp256k1, it’s fairly standard (ie, specified in NIST’s DSA Signature Standard (DSS) as are all of the secp* curves).

rybolov@ryzhe:~$ openssl ecparam -out key.test.pem -name prime256v1 -genkey
rybolov@ryzhe:~$ cat key.test.pem
—–BEGIN EC PARAMETERS—–
BggqhkjOPQMBBw==
—–END EC PARAMETERS—–
—–BEGIN EC PRIVATE KEY—–
MHcCAQEEIGkhtOzaKTpxETF9VNQc7Nu7SMX5/klNvObBbJo/riKsoAoGCCqGSM49
AwEHoUQDQgAEXmD6Hz/c8rxVYe1klFTUVOxxKwT4nLRcOLREQnC5GL+qNayqx7d0
Q+yal6sVSk013EbJr9Ukw/aiQzbrlcU1VA==
—–END EC PRIVATE KEY—–

Make a public key. This is poorly documented and I had to extrapolate from the RSA key generation process.
rybolov@ryzhe:~$ openssl ec -in key.test.pem -pubout -out key.test.pub
read EC key
writing EC key

rybolov@ryzhe:~$ cat key.test.pub
—–BEGIN PUBLIC KEY—–
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEXmD6Hz/c8rxVYe1klFTUVOxxKwT4
nLRcOLREQnC5GL+qNayqx7d0Q+yal6sVSk013EbJr9Ukw/aiQzbrlcU1VA==
—–END PUBLIC KEY—–

Make a test message:
rybolov@ryzhe:~$ echo “destroy all monsters” > msg.test
rybolov@ryzhe:~$ cat msg.test
destroy all monsters

Generate MD5, SHA-1, and SHA-256 hashes:

rybolov@ryzhe:~$ openssl dgst -md5 msg.test
MD5(msg.test)= a4a5e7ccfda28fdeb43697b6e619ed45
rybolov@ryzhe:~a$ openssl dgst -sha1 msg.test
SHA1(msg.test)= 4d1d1b917377448a66b94e1060e3a4c467bae01c
rybolov@ryzhe:~$ openssl dgst -sha256 msg.test
SHA256(msg.test)= efd54922696e25c7fed4023b116882d38cd1f0e4dcc35e38548eae9947aedd23

Make a signature, note that every time you make a signature with ECC it will be different.
rybolov@ryzhe:~$ cat msg.test | openssl dgst -sha1 -sign key.test.pem -out test.sha1.sig

rybolov@ryzhe:~$ cat msg.test | openssl dgst -sha1 -sign key.test.pem
0E!ÔøΩÔøΩÔøΩEÔøΩ-y
ÔøΩÔøΩ1K2ÔøΩÔøΩ›§{!ÔøΩv4+ÔøΩÔøΩÔøΩÔøΩ WÔøΩ ÔøΩcÔøΩÔøΩP≈ô—áÔøΩaÔøΩ*~)@aÔøΩ1ÔøΩJ>ÔøΩdÔøΩ

Make the signature readable/text by encoding it with Base64:
rybolov@ryzhe:~$ openssl enc -base64 -in test.sha1.sig
MEUCIGbR7ftdgICMZCGefKfd6waMvOM23DJo3S0adTvNH5tYAiEAuJ6Qumt83ZsL
sxDqJ1JNH7XzUl28M/eYf52ocMZgyrk=

rybolov@ryzhe:~$ wc -m test.sha1.sig.asc
98

rybolov@ryzhe:~$ openssl enc -base64 -in test.sha1.sig > test.sha1.sig.asc

Validate the signature:
rybolov@ryzhe:~$ openssl dgst -sha1 -verify key.test.pub -signature test.sha1.sig msg.test
Verified OK

OpenSSL is dumb here because it can’t read base64:
rybolov@ryzhe:~$ openssl dgst -sha1 -verify key.test.pub -signature test.sha1.sig.asc msg.test
Error Verifying Data
3077905144:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1320:
3077905144:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:382:Type=ECDSA_SIG

So we can use OpenSSL encode with the -d flag to make a binary version:
rybolov@ryzhe:~$ openssl enc -base64 -d -in test.sha1.sig.asc -out test.sha1.sig.bin
rybolov@ryzhe:~$ cat test.sha1.sig.
test.sha1.sig.asc test.sha1.sig.bin
rybolov@ryzhe:~$ cat test.sha1.sig.bin
0E fÔøΩÔøΩÔøΩ]ÔøΩÔøΩÔøΩd!ÔøΩ|ÔøΩÔøΩÔøΩÔøΩÔøΩÔøΩ6ÔøΩ2hÔøΩ-u;ÔøΩÔøΩX!ÔøΩÔøΩÔøΩÔøΩk|›õ
ÔøΩÔøΩ’RMÔøΩÔøΩR]ÔøΩ3ÔøΩÔøΩÔøΩÔøΩpÔøΩ` π
rybolov@ryzhe:~$ openssl dgst -sha1 -verify key.test.pub -signature test.sha1.sig.bin msg.test
Verified OK

We can also do a prverify which is to verify the signature using the private key:
rybolov@ryzhe:~$ openssl dgst -sha1 -prverify key.test.pem -signature test.sha1.sig.bin msg.test
Verified OK

Now to use this whole thing, you’ll need concatenate the signature with the massage and add a delimiter or send 2 messages, one with the message, the other with the signature. Any kind of special character like |!^% etc works great as a delimeter, so something like this works:

MEUCIGbR7ftdgICMZCGefKfd6waMvOM23DJo3S0adTvNH5tYAiEAuJ6Qumt83ZsLsxDqJ1JNH7XzUl28M/eYf52ocMZgyrk=destroy all monsters

destroy all monsters|MEUCIGbR7ftdgICMZCGefKfd6waMvOM23DJo3S0adTvNH5tYAiEAuJ6Qumt83ZsLsxDqJ1JNH7XzUl28M/eYf52ocMZgyrk=

Topics for further research:

I haven’t talked at all about key distribution. This gets real hard real fast just for the simple fact that you have to get an initial key to both ends of the conversation. You can do key rotation inband, but that first hookup is a logistical effort. Glad to hear ideas on this.

To get a smaller signature, use MD5 and secp112r1. Normally you wouldn’t create digital signatures using MD5 (US Government standard is moving to SHA-256), but it’s a tradeoff in paranoia/crackability with signature size. You have to do each of the steps manually because the objects for ECDSA only use SHA-1:

Hash the command
Encrypt the hash using the private key
Convert the encrypted hash to base64

You can use the OpenSSL shell prompt to save some keystrokes: openssl You can also call OpenSSL as a C library, which should work nicely for embedded code.

I’m interested in building a comparison table of the following items, I just haven’t had time to build a script to compare all the data for me:

ECC Curve
Time to Compute a Signature
Size of Signature
Relative key and signature strength

Similar Posts:

The post Micro Digital Signatures Howto first appeared on The Guerilla CISO.

IKANHAZFIZMA Ponders “The Move to Cloud”

rybolov — Thu, 17 Feb 2011 16:07:52 +0000

Similar Posts:

The post IKANHAZFIZMA Ponders “The Move to Cloud” first appeared on The Guerilla CISO.

Reinventing FedRAMP

rybolov — Tue, 15 Feb 2011 14:09:42 +0000

“Cloud computing is about gracefully losing control while maintaining accountability even if the operational responsibility falls upon one or more third parties.”
–CSA Security Guidance for Critical Areas of Focus in Cloud Computing V2.1

Now enter FedRAMP. FedRAMP is a way to share Assessment and Authorization information for a cloud provider with its Government tenants. In case you’re not “in the know”, you can go check out the draft process and supporting templates at FedRAMP.gov. So far a good idea, and I really do support what’s going on with FedRAMP, except for somewhere along the lines we went astray because we tried to kluge doctrine that most people understand over the top of cloud computing which most people also don’t really understand.

I’ve already done my part to submit comments officially, I just want to put some ideas out there to keep the conversation going. As I see it, these are/should be the goals for FedRAMP:

Delineation of responsibilities between cloud provider and cloud tenant. Also knowing where there are gaps.
Transparency in operations. Understanding how the cloud provider does their security parts.
Transparency in risk. Know what you’re buying.
Build maturity in cloud providers’ security program.
Help cloud providers build a “Governmentized” security program.

So now for the juicy part, how I would do a “clean room” implementation of FedRAMP on Planet Rybolov, “All the Authorizing Officials are informed, the Auditors are helpful, and every ISSO is above average”? This is my “short list” of how to get the job done:

Authorization: Sorry, not going to happen on Planet Rybolov. At least, authorization by FedRAMP, mostly because it’s a cheat for the tenant agencies–they should be making their own risk decisions based on risk, cost, and benefit. Acceptance of risk is a tenant-specific thing based on the data types and missions being moved into the cloud, baseline security provided by the cloud provider, the security features of the products/services purchased, and the tenant’s specific configuration on all of the above. However, FedRAMP can support that by helping the tenant agency by being a repository of information.
800-53 controls: A cloud service provider manages a set of common controls across all of their customers. Really what the tenant needs to know is what is not provided by the cloud service provider. A simple RACI matrix works here beautifully, as does the phrase “This control is not applicable because XXXXX is not present in the cloud infrastructure”. This entire approach of “build one set of controls definitions for all clouds” does not really work because not all clouds and cloud service providers are the same, even if they’re the same deployment model.
Tenant Responsibilities: Even though it’s in the controls matrix, there needs to be an Acceptable Use Policy for the cloud environment. A message to providers: this is needed to keep you out of trouble because it limits the potential impacts to yourself and the other cloud tenants. Good examples would be “Do not put classified data on my unclassified cloud”.
Use Automation: CloudAudit is the “how” for FedRAMP. It provides a structure to query a cloud (or the FedRAMP PMO) to find out compliance and security management information. Using a tool, you could query for a specific control or get documents, policy statements, or even SCAP assessment content.
Changing Responsibilities: Things change. As a cloud provider matures, releases new products, or moves up and down the SPI stack ({Software|Platform|Infrastructure}as a Service), the balance of responsibilities change. There needs to be a vehicle to disseminate these changes. Normally in the IA world we do this with a Plan of Actions and Milestones but from the viewpoint of the cloud provider, this is more along the lines of a release schedule and/or roadmap. Not that I’m personally signing up for this, but a quarterly/semi-annually tenant agency security meeting would be a good way to get this information out.

Then there is the special interest comment: I’ve heard some rumblings (and read some articles, shame on you security industry press for republishing SANS press releases) about how FedRAMP would be better accomplished by using the 20 Critical Security Controls. Honestly, this is far from the truth: a set of controls scoped to the modern enterprise (General Support System supporting end users) or project (Major Application) does not scale to an infrastructure-and-server cloud. While it might make sense to use 20 CSC in other places (agency-wide controls), please do your part to squash this idea of using it for cloud computing whenever and wherever you see it.

Ramp photo by ell brown.

Similar Posts:

The post Reinventing FedRAMP first appeared on The Guerilla CISO.

Happy New Year

rybolov — Sat, 01 Jan 2011 05:19:27 +0000

Believe it or not, this is a friend’s cat named Little Phat Man, and we cat-sat him over Christmas. Mrs Rybolov took the photo. I’ve been trying to get Phat into a lolcat for a long time.

Similar Posts:

The post Happy New Year first appeared on The Guerilla CISO.

DojoCon DDoS Video

rybolov — Thu, 16 Dec 2010 22:20:50 +0000

My DDoS presentation at DojoCon on Sunday. A big thanks to Marcus J Carey for organizing the con and Adrian Crenshaw for doing the recording.

Michael Smith, @rybolov DDoS from Adrian Crenshaw on Vimeo.

Similar Posts:

The post DojoCon DDoS Video first appeared on The Guerilla CISO.

no rly, iz protest

rybolov — Thu, 16 Dec 2010 13:03:47 +0000

Inspired by Anonymous, Operation Payback, and the “DDoS attacks as a legitimate form of protest?” article at ZDNet

Similar Posts:

The post no rly, iz protest first appeared on The Guerilla CISO.

WikiLeaks: Coming to an Agency Near You

rybolov — Thu, 09 Dec 2010 13:04:59 +0000

Nope, we’re not going to talk about ego trips, hidden agendas, or complete irresponsible transparency. This blog post is about some of the fallout inside the Government security teams.

The powers that be would like to remind you that downloading classified documents off the Intertubez does not make them unclassified. An anonymous source that I talked to last week gave me the info that they were busy tracking their users’ browsing behaviors so that if you (the hypothetical you) went to WikiLeaks and downloaded a classified document, the InfoSec goon squad would show up outside your cubicle to shred your hard drive because you had just been responsible for a classified spillage–ie, your unclassified desktop now has classified material on it and as per procedure the only way to deal with the situation is to overwrite your hard drive and reimage it. I have a couple thoughts about this:

Where were the InfoSec goons when their users were getting drive-by malware from questionable sites?
If it’s on TV, it’s not a “secret” anymore.
Don’t our InfoSec teams have something better they can spend their time doing other than being the WikiLeaks monitor?

And then there’s the Ambulance Chasing Department. According to a different anonymous source, the vendors have descended upon the State Department hawking their security solutions, including this gem of a webinar. Not quite sure what the webinar is on, except that they’re targeting you to sell something.

From: Prism Microsystems

Sent: Wednesday, December 01, 2010 10:01 AM

To: user@state.gov

Subject: Webinar: Prevent “WikiLeaks-type” Data Loss

Webinar: How to Prevent “WikiLeaks-type” Data Loss in Government Networks

Following the most recent publication of classified documents by WikiLeaks, government agencies are reviewing current provisions for protecting classified and top secret data – they are also researching best practices and alternative methods to monitor, prevent, and document data loss.

Attend this webinar to learn:

how the leaks happened

telltale signs of a leak

what you can do to prevent them

Leak picture by jillallyn.

Similar Posts:

The post WikiLeaks: Coming to an Agency Near You first appeared on The Guerilla CISO.

Interviewed for the “What It’s Like” Series for CSOOnline

rybolov — Tue, 23 Nov 2010 13:57:08 +0000

Joan Goodchild interviewed me about some of my experiences in the big sandbox and how I was good enough at avoiding IEDs to make it there and home again–an abstract form of risk management. Go check it out. And while you’re on the subject or for visuals to go along with the story, check out my Afghanistan set on Flickr, a random set of them are below….

Evolving the Physical Hacking at Security Conferences

rybolov — Mon, 22 Nov 2010 13:54:28 +0000

There has been a fun evolution at hacker conference for the past couple of years: the inclusion of hackerspaces. Hackerspaces fit nicely into the hacker ethos. But I’ve also heard grumblings via the tubes about the relevance of projects that they bring to hacker conferences, something along the lines of “Why has every security conference turned into a Maker Faire” (TM OReilly or somebody like that). The behind-the-scenes info is that each hackerspace has their own feel and what kind of projects they’re “into” and you get what the local hackerspace brings. While I consider hackerspaces booths at security cons to be pretty awesome, I have some suggestions for steering things back on track.

Things I would like to see in a petting zoo (yes, an “Evil Petting Zoo” and this is by no means an exhaustive list):

RFID widgets and software
Mag stripe readers
Barcode readers/writers (Duh, I can help out here)
Wifi stupid pet tricks
Bluetooth
WRT Routers
Smartcards and readers/writers
Single-board/mini computers

Of course, if you’re into any of these and have the hardware, software, or know-how, there is nothing keeping you from teaming up with hackerspaces at conferences and bringing some of your toys. Sharing is caring, y’alls. =)Similar Posts:

The post Evolving the Physical Hacking at Security Conferences first appeared on The Guerilla CISO.