Feeds:
Posts
Comments

Posts Tagged ‘Unisys Stealth’

If you want the full financial and operational value of Cloud Computing, then you want to use a public cloud. The advantages over private clouds include:

  • Low upfront costs.
  • Clear relationship between cost and benefit with pay-for-use model.
  • Easy to try new projects, easy to make change.
  • Flexible.
  • A wide choice of Service Level Agreement choices (SLAs).
  • Easy to provide a world-wide presence.

Of course, there are some public cloud disadvantages, the most critical being security, performance and availability. At this point in time, you can easily meet most performance and availability requirements from a variety of CSPs; security is more difficult. In a public cloud environment, you do not control physical access, and you have no control over who is sharing common infrastructure including networks, server hardware, and storage systems. But there is a way to secure your data both between your facility and your public cloud CSP and within the CSP’s infrastructure: combine Unisys Stealth with Amazon Web Services (AWS).

The basic principle behind Stealth is to only allow a device to communicate with another device if they share a Community of Interest, a COI.  A COI is nothing more than a group of people and servers.  Data can be shared freely within a COI, but must not be shared with any person or server not in the COI.  In the usual Stealth installation, a user’s COI or set of COIs is specified in the site’s identity management system, the system that is used to authenticate a user when the user signs on.

If you are responsible for protecting your company’s proprietary information, your customers’ private information, or concerned with compliance you should at least look at Unisys Stealth. If you are responsible for a government database involving individuals’ information or classified data, you should also be looking at Unisys Stealth.

I have talked about Unisys Stealth before, Amazon Secure Storage Service (Amazon S3), and the combination in “Secure Public Cloud” back in 2013. What has changed are some significant “under the covers” enhancements to Unisys Stealth, the incorporation of Stealth into the AWS Marketplace, and additional operational facilities to enable you to easily extend your datacenter into the AWS cloud to handle expected, or unexpected, sudden increases in resource demand.

The combination protects communication between your AWS virtual servers even within the same physical server, encrypts all communication among the servers in your data center and the servers in the AWS cloud, and controls access based on roles. You control the security access policies that define who and what can communicate, allowing you to isolate applications within your environment for business or compliance reasons.

Stealth subscriptions are sold through the AWS Marketplace; you get one bill from Amazon for everything including Stealth. It is available in every AWS region. Suddenly you can open a presence anywhere quickly and inexpensively, and react to unexpected growth from anywhere.

One of the most important characteristics of Unisys Stealth and AWS is that there is no back door. Unisys, Amazon, and any network component between do not have your encryption keys. Your government cannot force Unisys or Amazon to provide access to your data; they do not have a way to break in. Even if you are OK with your government gaining access to your information at any time without providing notice to you, you should be very concerned. If your government can get in, then so can any other government, cybercriminal or cyberterrorist by using the same back door for access. Another important benefit of Stealth is that even if a cybercriminal as able to insert malware on one of your servers in the AWS cloud, that server would not be able to transmit anything back to the cybercriminals because Stealth will prevent your server from communicating to any device that is not part of a community of interest that you have defined.

The last word:

Unisys has been around since 1886, and is one of the few survivors of the initial computer revolution designing and building commercial and government computers since the 1940s, computer systems that continue to perform “bet the business” functions. Support is a key element of that environment, and no matter how big or small your company is, you still get that enterprise level support from Unisys. Sure, Unisys has the on-line self-help site with all of the technical documentation and discussion you might want, but you can always pick up the phone and talk to a real person who is knowledgeable on the product, and is probably located within one or two time zones of you.

Curious? Check it out with a Unisys AWS test drive.

Comments solicited.

Keep your sense of humor.

Walt.

Advertisements

Read Full Post »

WS2003Windows Server 2003 (WS2003) was first released in, surprise, 2003. It replaced Windows Server 2000. Microsoft has released several derivatives including Windows Compute Cluster Server 2003, Windows Storage Server 2003, Windows Small Business Server 2003, Windows Home Server, and Windows Server 2003 for Embedded Systems.

WS2003 mainstream support ended in July 2010. On July 14, 2015, Microsoft will officially end extended support for WS2003. Microsoft will not release any updates, including security updates or patches, after this date.  At that point you can pay Microsoft for security fixes for WS2003, but it is very expensive and not delivered promptly. Most antivirus solutions will not be supported on WS2003 after 7/14/2015 meaning that there will be no signature updates for new vulnerabilities. Considering the rate at which new malware opportunities are discovered in all flavors of Windows platforms, any WS2003 systems you have in production will quickly become vulnerable. As one data point, there were 37 critical updates for WS2003 in 2013, 10 years after the product’s release. WS2003 will not pass any further security or compliance audits. Expect stiffer fines and other penalties if you experience a data breach where a WS2003 system is part of the application environment.

This should not be a surprise. Microsoft has published its support policy and product end of life chart on its web site for over ten years. There are a lot of servers still running WS2003 out there. A Microsoft survey in January 2014 showed about 22 million WS2003 systems in use. A large number of those are in small and medium sized businesses. Many of these SMB companies do not have large IT staffs or budget to make any kind of a migration.   There are probably at least 10 million WS2003 systems still in use today. Even many Fortune 500 companies are still dependent on WS2003, and most will not have migrated by the deadline, especially as it seems to take about six months to make the migration off WS2003.

Microsoft introduced Windows Server 2008 in 2008 as the successor product to WS2003. However, Windows Server 2008 is not the best destination for your WS2003 systems. Microsoft will end mainstream support for Windows Server 2008 on the same day that it ends all support for Windows Server 2003, July 14, 2015, while extended support ends in January 2020. If you need to move off Windows Server 2003 in any of its flavors, you are better served to jump to Windows Server 12. Windows Server 12 was generally available in September 2012 and released R2 in October 2013. Mainstream support for Windows Server 12 is scheduled to run until January 2018.

Microsoft provides assistance. Perhaps as an indication of their sense of urgency, the first thing you see on that Microsoft page is a count down clock telling you, down to the second, how long you have. Microsoft is, not surprisingly, pushing migration of your WS2003 servers to the cloud powered by Microsoft Azure. In some cases, that may make sense, but only if you want to make a significant change in your operations and procedures. Moving to the Cloud should be a business decision, not a technology decision. Like a lot of things involving cloud computing, the end point is often a better place to be, but getting there under a deadline can be risky. You should at least look at the material Microsoft provides to help in discovering which of your applications and workloads are running on WS2003, assess those applications and workloads by type, importance, and complexity, and choose a migration destination for each. For some of those workloads and applications, moving them to the Cloud may be the easier and less risky solution.

Your IT department probably has some good reasons for not migrating:

  • Your current server hardware may not support Windows Server 12.
  • Some of your mission-critical applications may not be supported on Windows Server 12.
  • You do not have sufficient financial or IT resources to make the migration while simultaneously keeping your IT environment running.
  • Unfamiliarity with Windows Server 2012.

The second may be the most serious, and may take the longest to fix. In the worst case, you may need to migrate to a different application.

In the meantime you may be able to mitigate some of the risk by restricting access to your WS2003 servers. Products like the Unisys Stealth Solution may help. It can completely isolate your WS2003 systems from the outside world, allowing communication only from the specific systems and users you permit. Since the protection is based on user identity, not specific network location or device identity, the rights of an individual change automatically when their role changes. As Unisys says, “You can’t hack what you can’t see.”

If you do not have the resources, get help. There are many companies out there with experience in migrating off WS2003. You do not have to go it alone.

The last word:

Windows Server 2003 is potentially as serious a security problem as Windows XP. Hopefully you are well past getting rid of that OS from your entire IT environment as have all of your business partners who share any proprietary, financial or customer protected data.

If you are running Windows Server 2008 you should start planning to move them to Windows server 12.

The keys to a successful operating system migration are planning and testing. These exercises can feel like a huge drain on your resources, and each migration can itself cause new problems. But you have to do it; you cannot afford to be vulnerable.

Comments solicited.

Keep your sense of humor.

Walt.

Read Full Post »

Last time I wrote about The Need to Protect Healthcare Data, or perhaps more importantly the potential cost of not protecting it. This time I want to talk about how to do that in a non-disruptive way that will probably save your organization money while significantly reducing the chances of a major data breach involving hundreds or thousands of patient records.   Of course the same approach can be used to protect any kind of protected information from exiting en masse in any line of business.

The key is to protect the “crown jewels” – the database that contains the data that must be protected. Normally, these systems are implemented as three-tier environments. To keep the picture and words simple, in this discussion each tier has only one server but in a real implementation each tier is usually composed of multiple servers for redundancy or to provide the necessary performance.

  • The data tier contains the database server that actually contains the database. This server contains the software that manages all access to the data: no one can access the data without eventually getting to the database server.
  • The application tier that controls the business logic that uses the database. These are the programs that implement information retrieval and update for the medical staff, capture information from medical device controllers, and handle data retrieval for meaningful use and billing.
  • The presentation tier is what interfaces with the user or another application system. It is often implemented as web services so that any device with a web browser can access the same information.

For example, when a doctor needs to see a patients chart from her tablet, she can use a browser or a special tablet application to ask for the current chart for “John Smith DOB 04/23/1945.” The tablet browser or application sends that request to the presentation tier, where the doctor is authenticated if necessary, then sends that request to the application tier. There a program formats a query against the database and sends it to the data tier. The data tier retrieves the information and sends it back to the application tier, who formats the specific information for the chart and sends that to the presentation tier. The presentation tier then sends it to the tablet browser or application for display to the doctor.

While this may seem like a complicated process, it nicely separates the operation so that, for example, a different kind of user device with completely different display characteristics can be easily added by changing only the presentation tier, and usually just making a single change that will work independent of the specific kind of transaction. Similarly, it allows the application layer to perform additional validation on a specific transaction, such as verifying that the doctor is permitted by HIPAA to see John Smith’s information.

The purpose of this requirement is to limit access to the application and data tiers to only those specific devices that have a valid need to access those tiers. In particular, only the servers in the application tier should be allowed to access the servers in the data tier, and only the servers in the presentation and data tiers should be allowed to access the servers in the application tier. There are, of course, users called administrators that require access directly to the application and data tier servers. These are the people who are responsible for the management and operation of the applications and database. In most organizations, there are just a few database administrators and application administrators who must have direct access into those servers.

This solution described there uses the Unisys Stealth Solution. Stealth uses state-of-the-art encryption, but the key principle behind Stealth is that it only allows a device to communicate with another device if they share a Community of Interest, a COI. A COI is nothing more than a group of people and servers. Data can be shared freely within a COI, but must not be shared with any person or server not in the COI. In the usual Stealth installation, a user’s COI or set of COIs is specified in the site’s identity management system, the system that is used to authenticate a user when the user signs on. If some device tries to access a Stealth-protected server or workstation without belonging to the same COI, then the Stealth-protected device is completely invisible; the Stealth-protected device simply will not respond to anything from that device.

StealthDCS

The picture represents each tier by a single server and shows one database and application administrator. As stated before, there are usually multiple of each. The red lines show the communications paths protected by Stealth. The black line represents clear-text traffic coming from the organizations internal network or over the Internet. The Internet traffic should already be protected by some form of encryption such as IPsec or SSL. There are three Communities of Interest (COIs) in the diagram. The green dots represent devices in the DB COI, the blue dots represent devices in the Application COI, and the yellow dots represent devices in the DB Administrator COI. Only the database Administrator and the application tier server can access the data tier server. Only the data tier server, application administrator, and presentation tier server can access the application tier server. Any other device attempting to access the data or application tier servers would be completely ignored.

Since the individual administrator’s COI is determined at log on time, it does not matter which workstation an administrator uses. When an individual signs on with a database administrator’s credentials, he now has the DB ADMIN COI and can access the data tier server.

One Stealth implementation can protect multiple databases that are in the same network segment, i.e., are visible from each other in the network. Otherwise you can replicate the Stealth implementation as needed.

This solution has no impact on existing applications and is invisible to end-users and even to the database and application administrators. Capital savings come from not requiring as much network infrastructure such as firewalls. Operational savings come from not needing to reconfigure firewalls or other network security devices and applications. If an administrator is added or moves on, simply change your identity management system. Stealth then automatically permits or prevents the individual from accessing the database or application servers.

If you do not have a tiered implementation or have collapsed the tiers onto a single server, and therefore allow end users to directly access the server containing the database then this mechanism does not help. Then again, not much would be able to help in this situation. You first need to separate your environment into multiple tiers so that any security solution can control access to the database and application servers.

The last word:

This mechanism does not protect against the accidental or deliberate loss caused by inappropriate actions of individuals who are authorized to access the data. This includes the file clerk who walks away from a logged-on workstation in a semi-public area, or the doctor who foolishly loads a couple of patient files on her son’s laptop at home. There are ways to reduce the chances of these kinds of incidents, and in super-sensitive environments it makes sense to make those investments. But they are very expensive and usually not worth the cost. While these errors are regrettable they rarely lead to fines or the risk of losing accreditation, or the CIO needing to find a new job.

As always, the key is to have a good security policy document and provide annual security training emphasizing to employees and contractors that you are serious about data security.

Comments solicited.

Keep your sense of humor.

Walt.

Read Full Post »