uncompiled.com

We’re pleased to release today a Preview Beta of a new AWS feature: AWS Identity and Access Management (IAM). IAM enables you to create multiple Users and manage the permissions for each of these Users within your AWS Account. A User is an identity (within your AWS Account) with unique security credentials that can be used to access AWS Services. IAM eliminates the need to share passwords or access keys, and makes it easy to enable or disable a User’s access as appropriate. IAM offers you greater flexibility, control and security when using AWS.

We are excited to offer you early access to this new functionality. As part of this Preview Beta, we are enabling you to programmatically add Users to your AWS Account, set groups and permissions for these Users, and enable your Users to call AWS Service APIs.

In the near future, we plan on adding support for your Users to login to the AWS Management Console. We also plan to extend the AWS Management Console to support IAM, providing a web-based interface to manage your Users, groups, and permissions.

Learn more about AWS Identity and Access Management Preview Beta at: http://aws.amazon.com/iam

Source

One core tenet of demilitarized zone (DMZ) design is to segregate network devices, systems, services and applications based on risk. Because of this, it’s crucial to carefully plan and design a DMZ because it may not be easy to fix major flaws in the DMZ’s design once it’s live. Here, Knowledge Center contributor Michael Hamelin explains how to design a secure DMZ for your enterprise.

We have come a long way when it comes to DMZs (demilitarized zones). It’s no longer a question of if your organization needs a DMZ, but rather, it’s now a question of how you should design one.

In computer security, a DMZ is a physical or logical subnetwork that contains and exposes an organization’s external services to a larger, untrusted network—usually the Internet. The original DMZ designs included a simple network separated from the internal network, where everything that needed access to the Internet was placed.

Today, there are as many DMZ designs as there are vehicles on the road. You have industrial trucks designed to simply transport goods as cheaply as possible. You have economy cars designed to save money. And you have exquisite Italian sports cars that are sure to make your friends jealous (and fast enough that you always arrive with plenty of extra time for a nice cup of espresso). DMZ designs are a lot like cars: there are many varieties which go by a lot of different names but they all serve the same purpose.

There are hundreds of names that we use for networks today but, essentially, there are internal networks, external networks and DMZs. They may be called partner nets, vendor zones, internal DMZs or security zones. But the reality is that they are all DMZs with a mix of ownership devices, connectivity and risk levels.

Goals of DMZ design

If you ask ten network architects about how to design a DMZ, they’ll come back with ten different answers. While variety is the spice of life, as an industry we should have some generally accepted practices of DMZ design.

One of the core tenets of DMZ design is to segregate devices, systems, services and applications based on risk. The goal is to isolate risk, so if something goes bad and the Web server is hacked, it is essential to know what other devices the hacker would have easy access to. Beyond segregation by risk, four other common design approaches are separation by operating system, data classification schemes, trust levels or business unit.

If you look at recent audit and compliance requirements, you’ll see that they include a growing number of specific technical design requirements. In some of the new requirements, we find the mandate to keep the Web and application tier separated from databases—a very good idea. We also see the move back to single purpose servers; for example, your Web server cannot also be your DNS server.

Four levels of DMZ design

Let’s break DMZ design into four levels, with Level 1 being the simplest design and subsequent levels providing more segmented security.

When we want to build a basic DMZ, we start with a single segment of the firewall. Let’s call this Level 1 in our DMZ design book. This design is fine if you have a few servers that need Internet access. But if you do any e-commerce transactions, you have already outgrown this design.

Many people make the mistake of keeping this design, placing the Web and application servers in the DMZ and the databases on the internal network. This is no longer acceptable. As database attacks become more targeted, the risk of having the database on the internal network requires a more sophisticated design.

Level 2 DMZ designs

A Level 2 DMZ would consist of multiple DMZ networks off of the firewall. This design is a substantial improvement over a Level 1 design. It allows traffic rules to be written between each DMZ for control and segregation. A good start is having separate DMZs for Web and application servers, databases, authentication services, VPNs, partner connections, e-mail and mobile services. This is very feasible today; most firewalls can easily handle tens of interfaces and multiple VLANs on each interface.

Level 3 DMZ designs

One problem often seen in Level 2 DMZ designs is that overly permissive firewall rules can lead to devices getting Internet access that should never have it. One way to rectify that is to use two firewalls. This design, which we’ll call Level 3, is built with an external firewall and an internal firewall. The DMZ is placed between the firewalls based on access restrictions. Inbound Internet access is allowed into the external DMZ via the external firewall—never directly routed to devices placed in the internal DMZ on the internal firewall. The internal network can talk to the internal DMZ but not the external DMZ.

This Level 3 DMZ design effectively separates Internet-connected devices and the services they require using just two firewalls with their own policies. Most security teams quickly understand the rule base design between externally accessible and internally accessible DMZs. The temptation is to create rules allowing inbound access from the DMZs to the internal network. This should never be allowed. All the services that are needed should be moved into DMZs so that internal networks are never exposed.

This restriction is often violated. A lack of coordination or communication between IT groups, the rush to deploy new applications, network complexity and other factors result in organizations building critical services on their internal networks.

Level 4 DMZ designs

Level 4 DMZ designs are where things start getting more complicated. A Level 4 scenario would most likely include deploying multiple firewall pairs in parallel along your border rail, and spreading your DMZs out among them, segregated by your choice of metrics. Most people choose to separate the firewalls into business or functional groups, while others like to separate them by trust levels.

Best practices dictate building separate firewall stacks based on Service Level Agreements (SLAs) and data classification. This creates a situation where there is an entirely separate firewall stack for PCI, separate firewalls for user services (such as Web browsing, FTP, e-mail, patching, etc.) and separate firewall stacks for business services. Consider business services placed in DMZs by SLA: 90 percent, 98 percent and 99.9 percent make for three good goals. Designing DMZs by SLA can streamline DMZ management and reduce business disruptions.

Conclusion

In closing, it’s imperative to place as much rigor as possible into the planning and design process. Assume that once the DMZ is live, it may not be so easy to fix major flaws in the design. Internal due diligence can be used as a way to establish strong lines of communication with other stakeholders—whether they are other IT folks, business owners, partners or managers. It can raise your profile within your company as a thoughtful risk manager and strategic thinker. And, perhaps most important, it will invite feedback outside your frame of reference. If one conversation with one person has a significant impact on DMZ design, wouldn’t you want to have that conversation before you design it?

Source

We’re always looking for ways to make AWS an even better value for our customers. If you’ve been reading this blog for an extended period of time you know that we reduce prices on our services from time to time.

Effective September 1, 2010, we’ve reduced the On-Demand and Reserved Instance prices on the m2.2xlarge (High-Memory Double Extra Large) and the m2.4xlarge (High-Memory Quadruple Extra Large) by up to 19%. If you have existing Reserved Instances your hourly usage rate will automatically be lowered to the new usage rate and your estimated bill will reflect these changes later this month. As an example, the hourly cost for an m2.4xlarge instance running Linux/Unix in the us-east Region from $2.40 to $2.00. This price reduction means you can now run database, memcached, and other memory-intensive workloads at substantial savings. Here’s the full EC2 price list.

As a reminder, there are many different ways to optimize your costs. When compared to On-Demand instances, Reserved Instances enable you to reduce your overall instance costs by up to 56%. You pay a low, one-time fee to reserve an instance for a one or three year period. You can then run that instance whenever you want, at a greatly reduced hourly rate.

For background processing and other jobs where you have flexibility in when they run, you can also use Spot Instances by placing a bid for unused capacity. You job will run as long as your bid is higher than the current spot price.

Source

The Cloud Security Alliance’s Certificate of Cloud Security Knowledge (CCSK) is now open for testing.

The industry’s first user certification program for secure cloud computing, the CCSK is designed to ensure that a broad range of professionals with responsibility related to cloud computing have a demonstrated awareness of the security threats and best practices for securing the cloud.

“Critical services are being provided via the cloud, creating an urgent need for cloud security skills among IT professionals,” said Jim Reavis, CSA executive director. “The CCSK is a low cost certification that establishes a robust baseline of cloud security knowledge. Combined with existing professional certifications, it helps provide necessary assurance of user competency in this important area of growth.”

The CSA’s CCSK already has broad industry support from numerous organizations that plan to certify employees, including eBay, ING, Lockheed Martin, Sallie Mae, Zynga, CA, CaseCentral, HCL Technologies, Hubspan, LogLogic, Fiberlink, McAfee, Novell, Ping Identity, Qualys, Solutionary, Symantec, Trend Micro, Veracode, VeriSign, Vordel, WhiteHat Security and Zscaler.

“We have already been leveraging the CSA’s ‘Security Guidance for Critical Areas in Cloud Computing’ as a best practices manual for our information security staff,” said Dave Cullinane, CISO and VP for eBay. “We plan to make this certification a requirement for our staff, to ensure they have a solid baseline of understanding of the best practices for securing data and applications in the cloud.”

Discounted pricing of $195 for the CCSK exam is available through Dec 31st; regular pricing at $295 begins January 1st.

Source

Trend Micro is blazing a new trail with a service called SecureCloud intended to give enterprises a way to encrypt data in cloud-computing environments.

SecureCloud allows you to maintain control over the encryption key used to secure data stored in the Amazon EC2, Eucalyptus or VMware vCloud cloud infrastructures. Other cloud-computing variants could be added in the future.

“IT operations may be firing up [a remote virtual machine] image but we have security validating the integrity, and it’s encrypted until it hits the cloud, and it’s encrypting data at rest,” according to Todd Thiemann, senior director of data center security and marketing at Trend Micro.

He notes that SecureCloud allows the IT department using either public or private cloud-computing services to answer the basic questions, “Is this image OK? And is it mine?”

Now in beta with general availability expected by year end, SecureCloud is provided through a Web site portal and makes use of policy-based encryption to allow access to a virtual-machine image as well as storing related activity logs.

In addition to offering the security service, Trend Micro is looking at making comparable software available to companies for on-premises use.

In a separate announcement, Trend Micro also unveiled an antimalware protection module for its VMware server security software, Deep Security 7.5. It includes integrity monitoring, log inspection and stateful firewall capabilities, and leverages the most recent VMware vShield Endpoint APIs. Trend Micro Deep Security 7.5 is expected to ship in October.

Source

For 12% of CIOs, hearing complaints from employees over IT security measures — specifically, limits on their access to certain types of websites or networks while using the office network — is a common occurrence. Meanwhile, 29% of CIOs say such gripes are at least “somewhat common.”

The numbers come from a survey of more than CIOs, selected randomly from companies in the United States with 100 or more employees, conducted by staffing firm Robert Half Technology.

“There will always be employees who feel IT security policies are too restrictive,” said John Reed, executive director of Robert Half Technology, in a statement. “But in most situations, robust information security measures are necessary to protect sensitive data and an organization’s network integrity from increasingly sophisticated threats.”

On the other hand, said Reed, if too many people are complaining, then maybe it’s time to reevaluate whether an organization’s security policies have come down on the wrong side of the security-versus-productivity equation.

Rather than worrying whether their security policies are too restrictive, however, many organizations have a more fundamental problem: they lack any security policies, or else mechanisms for automatically enforcing those policies.

The result in either case is the same: employees often take their chances, ignoring any rules that they think are slowing them down, such as social networking restrictions or file transfer rules. According to numerous studies, when it comes to flouting security policies, IT personnel can be amongst the worst offenders.

But if corporate security or web access rules are cramping your style and making it harder to do your job, Reed recommends speaking up. “Some policies may simply be outdated and no longer make sense,” he said. “Asking someone in your organization’s IT department why access is restricted is often one of the quickest ways to resolve an issue.”

If policies aren’t judged to be outdated, he suggests talking up the business reasons for why they should change. “If employees can’t access a client’s website or a professional networking site that can generate business, it will probably be an easy case to make,” he said.

Source

Continuing its cloud computing buying spree, IT management software provider CA Technologies announced Monday that it plans to acquire authentication solutions provider Arcot for $200 million.

The acquisition, expected to close by the end of September, will expand Islandia, N.Y.-based CA’s existing security portfolio by adding fraud prevention and advanced authentication functionality to its existing identity and access management (IAM) offerings. Additionally, the acquisition will allow CA to accelerate its delivery of identity and access management (IAM) solutions from the cloud, CA said in a statement.

Dave Hansen, general manager for the security business at CA Technologies, told SCMagazineUS.com on Monday that customers want to take advantage of the cloud but are concerned about security and want authentication to ensure the right people are accessing the right information.

“People are starting to realize – and this [acquisition] reinforces it – that cloud computing is here, and people want to take more advantage of it and feel like they have the security and control around it to deliver a reliable service,” Hansen said.

Founded in 1997, Sunnyvale, Calif.-based Arcot is a provider of authentication and fraud prevention solutions that can be delivered as cloud services or deployed on premise. Arcot’s technology is used to help prevent fraudulent transactions for about one million credit card transactions each day. CA said that combining Arcot’s technology with its SiteMinder web access management portfolio will enable the company to further help customers reduce risk, support regulatory compliance, and confidentially secure business transitions.

Arcot’s operations and approximately 165 employees will become part of CA’s security business. The acquisition will allow CA to compete with RSA, which also provides advanced authentication solutions, Hansen said.

This is the seventh cloud computing acquisition for CA in the past 14 months. Earlier this month, CA acquired 4Base, a virtualization cloud infrastructure consulting firm. Other recent CA cloud acquisitions include Nimsoft, a cloud monitoring provider; 3Tera, a developer of solutions used to build cloud applications; Cassatt, a provider of cloud computing software for data centers; NetQoS, a network management software and services firm; and Oblicore, a service-level management technology vendor.

Source

In an effort to broaden its footprint in the market for security and identification products, 3M Co. has agreed to acquire Cogent Inc., a Pasadena-based provider of biometrics systems that focuses largely on public sector agencies in law enforcement and homeland security.
Under the deal, disclosed Monday, 3M will acquire all of Cogent’s outstanding shares at $10.50 per share, a premium of 18% over Friday’s closing price of $8.91. The agreement, subject to shareholder’s acceptance and other conditions, is expected to close in the fourth quarter, 3M said.

Cogent shares were up 21.03%, to $10.79, in early afternoon trading Monday. That its shares were trading above 3M’s offer was a sign investors believe other vendors might try and top 3M’s offer, a move that could kickstart a bidding war akin to Dell and HP’s contest to acquire storage company 3Par.

3M’s shares were off .75%, to $80.39, as it cautioned the deal would reduce earnings by $0.09 to $0.10 in the first year.

3M officials said acquiring Cogent would bring their company deeper into key growth markets like border and airport security. “Cogent Systems has done a tremendous job establishing a strong presence in the biometric industry,” said Mike Delkoski, VP and general manager for 3M’s Security Systems Division, in a statement.

“Adding Cogent Systems products to our business strengthens our product portfolio and services in high security credential issuance and authentication systems and positions 3M’s business in law enforcement applications. It also expands our reach into access control and other commercial ID and authentication applications,” said Delkoski.

The U.S. Department of Homeland Security is a key Cogent customer. Cogent has teamed with ARINC, FLO Corporation, and International RAM to develop the iQueue pre-approved traveler program for use at airport security checkpoints around the country.

Other Cogent customers include New York State, the UK national post office, and the Belgian federal police department.

Cogent founder and CEO Mingh Hsieh is expected to remain with the organization following completion of the acquisition. “3M can accelerate our growth and extend our reach in global border control markets, law enforcement and commercial applications,” said Hsieh, in a statement.

Source

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

Eucalyptus Systems, supplier of Amazon EC2-compatible software for building the private cloud, has brought out version 2.0 of its Eucalyptus open source system.

The Santa Barbara, Calif., company was founded to support the output of the Eucalyptus open source project, founded at the University of California at Santa Barbara’s computer science department. Prof. Rich Wolski and associates produced interfaces compatible with Amazon Web Services’ EC2 APIs and packaged them together as a way to start building out an enterprise cloud.

Eucalyptus 2.0 is the second major release of the open source code. In it, “we have improved scalability all over the product,” said Marten Mickos, CEO, in an interview. The firm provides technical support for Eucalyptus open source code. The open source version is not to be confused with the Eucalyptus commercial Enterprise edition, also labeled 2.0, although based on a pre-2.0 version of the open source code.

The Eucalyptus open source code is issued under the GPL, contains features and functions ahead of the Enterprise edition, and can be freely downloaded. The firm is seeing 12,000 downloads in peak months and Eucalyptus is included in Canonical’s Ubuntu Linux distribution, he said.

Eucalyptus scales across a larger server cluster more easily because the 2.0 version “has been clearer about the segregation of tasks. We no longer locate the cluster controller and the node controller on the same node,” where they sometimes ended up in contention over resources, Mickos noted. The former CEO of MySQL, now part of Oracle, joined Eucalyptus Systems in March.

Version 2.0 supports iSCSI disks as elastic block store volumes and allows the cloud builder to place an iSCSI storage controller on any server in a cluster, including outside the cloud domain of the cluster, if he chooses, Mickos said.

Version 2.0 also supports the open source virtio, an API for virtualizing I/O that is used by the open source KVM hypervisor. KVM is included in distributions of Red Hat Enterprise Linux and Novell’s SUSE Linux Enterprise System. Virtio uses a common set of I/O virtualization drivers that are both efficient and potentially adaptable for use by other hypervisor suppliers, Mickos said. Virtual I/O consists of a virtual machine sending both its communications traffic and storage traffic through the hypervisor to a virtual device, rather than through a server’s network interface card or host bus adapter. From the virtual device, it can be moved off the virtualized server into the network fabric and handled more efficiently there.

Eucalyptus 2.0 also supports retrieval of specific versions of objects stored in Walrus, the Eucalyptus storage system that is compatible with Amazon’s S3 storage service. Users may perform version control on objects as they are stored in Walrus and retrieve a specific version, as needed.

Eucalyptus to some extent now mimics the slogan of the OpenStack project, started recently by Rackspace, which claims it’s building governance software for a million-node cloud, a prospect that even the largest service providers have yet to attain.

“Sure Eucalyptus can support a million-node cloud, but the more important question is how large an application can you run on your cloud” and how effectively can you manage it there with your cloud software. Eucalyptus is concentrating on effective management for private clouds, not massive public infrastructure providers, Mickos said.

Source