Your first real lesson about locking down a host was how to reduce its attack surface. You learned how to disable services using /etc/inetd.conf. Then you learned about rc.d and how to prevent unnecessary services from being launched at startup. Next, maybe you configured the Xserver to disallow remote connections or moved on to removing setuid permissions from files. As you worked, you’d periodically re-scan the box to gauge progress, asking yourself “have I removed everything I don’t need?” The underlying motivation, of course, is that an attacker can’t hack something that isn’t there.

You learned how to extend those concepts to the network — configuring firewall rules, router ACLs, VLANs, etc. Segmenting the network. Creating a DMZ. No need to dwell on this, you get the idea.

Eventually, people realized that applications had an attack surface too. Web servers and application servers got a lot of attention, followed closely by custom web applications. “What do you mean you can execute SQL queries against my database? That’s impossible, I have a firewall!”

Some companies, the ones who could afford it anyway, started to build security into their development cycle. Doing threat modeling during the design phase made sense, because hey, it’s much cheaper to fix security holes in a whiteboard drawing than it is to rewrite your authorization module from scratch after it’s in production.

Let’s talk strictly about custom web applications now. What I’ve observed is that most development groups, even the ones who actively engage in threat modeling, do not understand their web application’s attack surface. The lead architect can whiteboard a high-level diagram of all the major components and how they interact. Individual developers can go a bit deeper, telling you which files they touch, what database permissions they need, or how various pieces of data are encrypted in storage. At the end of this exercise you have a complete picture of the processes, data flows, protocols, privilege boundaries, external entities, and so on, and you’re well on your way to understanding all of the potential attack vectors.

Or are you?

What often gets overlooked or glossed over is the impact of external libraries or packages. Nobody writes everything from scratch. A typical list of third-party libraries for a Java-based Web 2.0 application might include DWR, GWT, Axis, and Dojo, plus about 30 other libraries to do everything from logging to parsing to image manipulation. Nine out of ten times, the libraries will be installed in full, using the default configuration from page one of the README file.

Why is this relevant? Because just as those old Unix boxes exposed unnecessary services, libraries expose unnecessary code. Let’s say you installed Dojo to simplify the process of creating an HTML table with rows and columns that can be sorted on demand. Did you remember to remove all the .js files you didn’t need? Or maybe you installed Axis or DWR or anything else that has its own Servlet(s) for processing requests. Have you compared what that Servlet can do against what you need it to do?

A fictitious example may help illustrate further. Imagine you just downloaded a new library called WhizBang. You follow the installation instructions to define and map two servlets in your web.xml file, WhizServlet and BangServlet, and you configure it to integrate with your web app. After a bit of trial and error, it’s functional. Yay! This is where most developers stop.

Nobody asks, “how much of this do I actually need?” Case in point, what if your application only uses WhizServlet? BangServlet is still exposed, and you don’t even use it! Similarly, what if WhizServlet takes an “action” parameter which can be either “view”, “edit”, or “delete”, and your application only uses “view”? You’re still exposing the other actions to anybody who knows the URL syntax (pretty trivial if it’s open source). You wouldn’t expose large chunks of your own code that you weren’t using, so why should it be any different with libraries?

This post is getting kind of long so I’m going to split it up. In the next post, I’ll continue the discussion of attack surface minimization, as well as some of the tradeoffs that go along with this approach.

If somebody asks you "Can you have a secure cloud-based service?" - you need to ask back "What do you mean by "you"?" Seriously! Let's go back to the old joke that "the only computer that is 'secure' is the one that is turned off, cemented into a big concrete cube and stored in a locked room." But whose room? Do you own the room where the aforementioned concrete cube is stashed? No? Then maybe it is no longer 'secure' ... Think "concrete cube in the clouds - then BAM!" :-)

Joking aside, if you think that a system that is located somewhere remotely (you don't control physical security) + Internet accessible (you don't control network security) + neither written  nor audited by you (you don't control application security) can be secure, than yes, most certainly you can have a secure cloud-based service.  This also reminded me about this post by Richard where he classifies people into "two camps: those who trust their products to operate as expected and those who do not."

Now, let's review some of the issues with security of cloud based services.

First, is there public vulnerability research that made MS IIS and OpenSSH (and OpenBSD) the paragons of software security? No, this part is completely screwed up today as only criminals are "allowed" to do vulnerability research of cloud based-services (and web applications).  Comparison here is not in favor of "the clouds," and "legacy" software approach wins hands down (want trusted apps? go audit them!). To remind yourself what the world looked like without public vulnerability research, think back to early 90s: "hot new exploit - telnet as 'root' without any password" (this is where web security stands today, pretty much).

Second, can you make sure that only you will see the sensitive data (or even regulated data: PHI, credit cards, passwords, financials, etc)? Maybe, if you take care of it. As Mike R  puts it : "Basically, you can't be sure anything is secure in the cloud, so that means you have to secure it yourself. That means building your applications with some semblance of data protection [...] But ultimately if you can't prove your data hasn't been tampered with and that it's open for anyone to steal, then I suspect your auditor may have a bit of an issue with that."

Third,  can you log and audit access to your information, stored and processed somewhere in the cloud? Maybe, if you chose the provider that allows you to do it. For example, I hear that Salesforce.com access logs are good enough to enable most things you can do with OS logs. Otherwise, well, keep begging them to build it; there is no appliance you can buy to plug this hole.

Finally, if we are insane because we use software, what about cloud services?  Sorry, multiply that insanity by 10x. Replace today's mantra "I trust my software vendor" with "I trust my cloud provider, their software developers, their outsourcers (if any), the other vendor they mashup with, my ISP (and its ISP, and its ISP,  and its ISP, etc, etc), my cloud provider's ISP (and its ISP, and its ISP, etc, etc, etc)  and ... oh, wait ... and your software developers who wrote the code that connects to the above in-the-cloud service." Cool, isn't it? :-)

This paper also reminds us about the business angle: "Remember that the storage provider has less to lose than the customer"  [that is you, BTW]. At this point somebody has got to ask "is that dirty C-word hiding somewhere here? Is there a compliance angle?" You bet. And it is "simple", really: just compare a) and b) here:

a) you manage a system that contains financial records (SOX anybody?), you screw up and they are lost OR you don't screw up and they are OK (not lost)

vs

b) you DON'T manage a system that contains financial records (SOX still?) - it is in the cloud, you DON'T screw up and they are still lost since your cloud provider screws up.

Who do you think will go to jail?  And don't even get me started on the breach disclosure law angle here (if they lose your data, than you are in violation of SB1386 - that is at least my guess ...)

By now, it should be painfully obvious to any and all of my readers that "in the cloud services" are indeed the future of IT! :-) Yes, and security is a great career - with no shortage of challenges to overcome or tall peaks to climb ... now and ever. That is why I love it.

• First, watch Dave Aitel beats the dead horse of academic security "research." Quote: "people who write papers in LaTeX two-column format end up saying the sky has a high negative trajectory." (other examples)
• I work for a vendor, but I am not "vendor scum." What is the difference? If you write a paper about a fake trend or about a non-existent phenomenon (that your marketing department created) with the sole intention of selling your product while masquerading your piece as "objective content", you will probably be called "vendor scum." Example: do you know why insiders are dangerous? Because of telnet and modems (no shit!) :-)
• Rich Mogul drop-kicks GRC. Then kicks it in the balls. Then steps on it. Fun read, for sure.
• Did somebody just utter "ROI"? Yeah - and that means katana blades sharpened, flamethrowers charged, pet trolls enraged :-) Yes, the beast is back - with a vengeance. Bruce Schneier hits it with +5 Flaming Blade, it doesn't die, it bites back ... again. If you love/hate ROI, read these. And Mike R comment here. Can we just replace the "R"-word with "economic measure of security" or "security efficiency?"
• Does anybody with at most half a brain believes that "almost one out of every three individuals who were informed of a data security compromise involving their personal data have ceased doing business with the company that experienced the incident" (source here and more commentary here)? Well, same people who believe FBI/CSI surveys, I guess :-) UFO? Spoon bending? Santa Claus anyone?
• NEWSFLASH!!!! Employees needs to be monitored!!! Wow!!! Reeeeally? Well, it is news to some people. Mike R makes good fun of them here.
• Harebrained paper about PCI and using cards (credit and debit), which serves as a perfect illustration of how some people perceive risk. Repeat after me: you are not liable for mis-use of your credit card, your bank is. Debit card? Very different story!
• So, risk, yes. A really good piece about risk is here. Then again, it is RiskAnalys.is? :-) More on risks of compliance stuff (also good) is here.
• Richard clearly, succinctly, brilliantly explains the "security chasm" here by commenting on Greg's article (featured in my previous FRoS): "The first camp spends more time talking about "enabling business" and "elevating the infosec conversation" while the second camp deals with the mess caused by the first world's ignorance of security problems."
• Security reading? Nah, fun security listening (that is, unless you are sick of hearing about RSA 2008 again), where we discuss - yes, you guessed right! - past RSA 2008 show.

Enjoy!

Sure, I could use some of the modern rootkits that talk outside of the TCP by sending single packets but some anti-DDoS boxes out there stop that sort of connection from even hitting a box. They do this for flood protection. They wait for a full TCP state to be initiated before they connect to the web server behind them (similar to a proxy server actually).

Here’s where some programming skill could come into play. Why not re-program a web-server to also listen as if it were an IRC server or telnet or something else for back and forth real-time communication. We already have root access, so it’s easy enough to start and stop the process. It’s also fairly easy with some programming to create a switch in the code, to look for a different string and jump into a different mode. It could be a clever way around a fairly complex set of circumstances. Anyway, yet another odd thought.