uncompiled.com

There’s a tremendous buzz today about cloud computing, but before outsourcing your critical business systems to the cloud let’s review some security concerns.

The most critical business applications deal with corporate HR, finance, credit card, and other sensitive data. If any of this information is compromised lawsuits may ensue and your corporate brand is tarnished. This is a nightmare that could lead to customers avoiding purchasing your products or services. How can cloud computing effectively protect sensitive data?

There are three areas that need to be addressed to effectively push your applications into the cloud:

Let’s start with defense in depth.

First, put sensitive data in a second tier of firewall segments behind the main corporate firewalls. This second-tier firewall and corresponding network shields sensitive applications and their data from being easily accessed if the Web-facing firewalls are breached. For example, let’s look at grocery stores. It would be wise to deploy at least four firewall/network segments: one for HR data, one for financial data, one for credit card PCI (Payment Card Industry) data, and one for services that the other segments share. The segment containing services that are shared could contain common support services such as network and systems management, encryption and PKI functions, access control services, and security event management functions.

Another architectural implementation that protects corporations from internal data theft is the creation of a Tunneling Access Protocol. The Tunnel Access Protocol is an access control function that forces all administrators to log information before they perform administration on segment systems. Hence, all administrative access is tracked, discouraging internal theft of information

The second area that needs addressing is the analysis needed to determine successful migration of the application to behind the cloud’s second-tier firewalls. I recommend starting with the application design document first. It gives you a big-picture understanding of which business need the application performs, what middleware is used, what databases are used, and what protocols it uses. It also often contains the logical architecture.

It is important to focus on all the systems the application interacts with. Your security team will have a variety of information collected about the application: what data is sensitive, how and what tools are used to encrypt the data, and penetration testing results if it is a Web-facing application. Also, I recommend creating a protocol diagram showing all servers and their IP addresses, the protocols being used, and the protocol (TCP or UDP) ports being used. This network view specifically shows which servers need to talk to each other and what protocols (ports) they will use to do it. It is not necessary to include switches, routers and other network infrastructure components because the protocols/ports just ride over them. If the protocol diagram is thorough, it should be a simple step to create the firewall rules. Firewall rules are made up of source and destination IP (Internet Protocol) addresses, protocol used, and ports that ride on top of those protocols.

Lastly, I recommend a thorough collection of system and application metadata. The need to port your application well requires this work. Plus, if you have a disaster, business interruption or want to pull your application from the cloud — you need this data. System information exists per firewall/network segment. All applications share the same system data such as the same firewall, routers, switches, encryption algorithm (if used for all applications in a segment), and storage subsystem. System metadata includes vendor, model, software release and version, and other system-wide configuration data. Application data is similar but it addresses load balancers, encryption method, middleware, database, server hardware and operating system, and services, protocols, and ports that ride on top of those systems. Application metadata includes vendor, model, software release and version, and other application configuration data.

The next debate is where this metadata should be contained. I recommend containing this information in a hierarchy in a LDAP repository. I would create two tiers in the directory: one called Segment System for each of the four segments in the example above, and lastly one called Application for all applications within a given segment. This ordering enables a systematic collection of all metadata so that sensitive cloud applications can quickly be deployed. And, most importantly, it enables a quick deployment of the application and/or segment into a cloud.

In summary, migrating critical cloud applications involves putting data behind a second tier of firewalls. Common services exist in one of the segments that can be shared by all segmented applications. Applications should be in separate segments based upon the type of data that is being protected such as credit card data, finance data and HR data, and services that are shared. A variety of documentation should be created and/or reviewed to make sure that the porting of applications behind the second-tier ‘deep theater’ defense firewalls goes well. This collected metadata is from a hierarchy of two layers: common system per segment and different applications within each segment. I recommend the metadata be saved in a directory where it can be easily retrieved.

Source

On Tuesday, hacker Samy Kamkar demonstrated a way to identify a browser’s geographical location by exploiting weaknesses in many WiFi routers. Now, he’s back with a simple method to penetrate hardware firewalls using little more than some javascript embedded in a webpage.

By luring victims to a malicious link, the attacker can access virtually any service on their machine, even when it’s behind certain routers that automatically block it to the outside world. The method has been tested on a Belkin N1 Vision Wireless router, and Kamkar says he suspects other devices are also vulnerable.
“What this means is I can penetrate their firewall/router and connect to the port that I specified, even though the firewall should never forward that port,” Kamkar told El Reg. “This defeats that security by visiting a simple web page. No authentication, XSS, user input, etc. is required.”

Kamkar’s proof-of-concept page forces the visitor to submit a hidden form on port 6667, the standard port for internet relay chat. Using a hidden value, the form surreptitiously coerces the victim to establish a DCC, or direct client-to-client, connection. Vulnerable routers will then automatically forward DCC traffic to the victim’s internal system, and using what’s known as NAT traversal an attacker can access any port that’s open on the local system.

For the hack to work, the visitor must have an application such as file transfer protocol or session initiation protocol running on his machine. The hack doesn’t guarantee an attacker will be able to compromise that service, but it does give the attacker the ability to probe it in the hope of finding a weak password or a vulnerability that will expose data or system resources.

“Most people have this false sense of security that ‘well, I’m behind my router, nobody can connect to my ports,’” said Kamkar, the hacker behind the notorious Samy Worm that in 2005 took MySpace out of commission by adding more than 1 million friends to the author’s account. “If you’re going to keep a service open to the world, you’ll probably have more upkeep” to make sure it’s secure.

Source

Akamai Technologies is introducing a cloud-based managed service called Web Application Firewall it claims will head off the bulk of Web applications attacks before they get inside corporate data centers. Application firewalls within Akamai’s network of more than 55,000 servers worldwide weed out the most common application exploits including SQL injection, cross-site scripting among others listed by the Open Web Application Security Project as the most prevalent.

Akamai says the service is compliant with the wide-area file services (WAF) program specified in Payment Card Industry standards for Web application firewalls. The service is based on the core rule set of the open source ModSecurty Web application firewall, which is administered by Breach Security. “It stops the big, bad, well-understood stuff,” says Sanjay Meta, senior vice president of Breach. “Anything more elegant, not findable by a signature, you need something more sophisticated. You can only do so much at the edge.”

He describes the Akamau service as complementary to corporate-based WAFs, but valuable because it reduces the amount of traffic the private gear has to filter, and it can cut the bandwidth chewed up by malicious traffic. Akamai says it has blocked attacks headed at customer networks at 100Gbps, which would be enough to swamp the privately owned filtering resources of many businesses. Customers who also buy Breach’s WebDefend Global Event Manager management platform can tap into Akamai’s worldwide security-event data to find out details about the attacks that the service blocks, Breach says.

Pricing for Web Application Firewall depends on how many applications customers want to protect and the size of their Internet connections.

Source

Version 1.2 of GreenSQL is now able to protect PostgreSQL as well as MySQL. GreenSQL is designed to protect databases against SQL injection attacks and other unauthorised changes, in a similar fashion to a firewall protecting a network against TCP/IP outside attacks. The new version also provides a graphical user interface for monitoring the database firewall.

GreenSQL is run as a proxy between applications and database servers. It actively analyses the incoming SQL commands and can then act on the results according to the selected mode. Simulation mode blocks nothing but records the analysis in GreenSQL’s own database and notifies the administrator of suspicious queries. Blocking mode on the other hand uses the database and it’s heuristic engine to find and block suspicious queries.

Source

Only a few years ago, experts warned of the precarious state of website security – stating that it was only a matter of time before malicious attacks escalated if we did nothing. Some listened, most didn’t, time marched on, and now the grace period is over. Daily headlines are now a ticker tape of breaches. Serious attacks against 7-11, Hannaford, Heartland, U.S. Army, Twitter, Apple, the New York Times, the University of California, Berkeley, and thousands of other prominent and lesser-known organizations have had their insecure web application code targeted. According to Websense, “70 percent of the top 100 most popular websites either hosted malicious content or contained a masked redirect to lure unsuspecting victims from legitimate sites to malicious sites.”

Even for the most proactive organizations, finding and fixing flaws in website code is complex, time and resource intensive, and not immune to the accidental introduction of new risks. IT security often has difficulty convincing software development groups that feature enhancements or operational bug fixes should be disrupted to address security issues which may have yet to cause an incident. Additionally, for organizations that have outsourced part or all of their custom development efforts, this might result in the rehiring or attempt to rehire consultants that have long since moved on.

Source