Should government employees be allowed to use personal systems? Many government CIOs/CISOs are reluctant and prohibit employees from using non-government furnished equipment. This is problematic for many reasons including:
- Organizations have an increasingly mobile workforce that needs to be able to work from anywhere. On the government side, it may be the census taker, the CDC scientist in a 3rd world country, a DEA agent in the field or our soldiers in the Middle East. All of these roles need access to the applications and information critical to their mission (and sometimes, even their lives).
- The government has had a strong telework mandate for years now, but the scope of outfitting every employee with government-furnished equipment (GFE) at home is cost prohibitive. And requiring a GFE doesn't fit how today's workforce operates nor does it address the need for emergency ad-hoc access.
- Many agencies' continuity of operations plans aren't practical as they require a "check-out of GFE resources". Two years ago, during the Potomac River floods, many of our agencies were under water and unable to supply GFE to their workforce...same was true during Hurricane Katrina.
- A younger workforce, or "Echo Boom" generation, doesn't want to use GFE, they want to use their personal systems! The ability to utilize a platform of choice is increasingly a recruiting/retention issue - especially with mobile devices. The US Government is expected to lose 70 percent of its existing workforce by 2011 and needs to address all of the factors that lead to attrition. This is one of the largest issues in government. (See my recent blog posting)
Aside from the mounting pressure for unfettered access, security concerns for government systems often greatly exceed those of civilian systems. How do you hand someone a laptop with a large hard disk, give them access to a wealth of information, allow that information to be distributed and maintain needed security controls? Even with encrypted hard drives, the control of physically distributed data continues to lead to data loss and distribution worries. The root problem transcends the GFE vs. personal debate.
The reaction we're seeing from the government in disallowing the use of personal systems and tightly controlling GFEs is indicative of a bigger problem: the client/server computing model implies the deployment of a "trusted client". Increasingly, the inability to provide and maintain a trusted client at all times has resulted in data loss and compromise. It's because the "trusted client" model does not allow for the security controls that are necessary and essential for a distributed workforce.
To accommodate security for today's distributed workforce, consider a model where defined applications and services are delivered - not deployed. By adopting the delivery model, stringent controls can be applied to applications and desktops that remain under the protection of the datacenter, with only keystrokes, mouse clicks, and screen refreshes traversing the network. In this delivery model, authentication, logging, the ability to copy, paste and print can all be controlled on an application-by-application and user-by user basis. Combined with the abstraction and isolation of virtualization, resources and systems are separated from each other with a security boundary that allows sensitive data to be accessed on personal systems.
Embracing delivery and virtualization allows the government (and other organizations) to provide users the freedom of a "platform of choice" and the organization to maintain the required security controls. Don't make a federal case out of the laptop debate - deliver a solution that truly addresses the underlying needs.
[by Kristin Taylor and Kurt Roemer]
Everybody has heard the stories and wants to believe - but there's no such thing as "PCI Compliant" products*.
People are constantly asking the question: Is "Product X" PCI compliant? The short answer is: No.
The long answer requires some careful explanation.
PCI sets forth 12 major requirements for an organization to meet, with the result of meeting these requirements culminating in an attestation of compliance. The PCI auditor verifies that the intent of PCI has been met, and compliance is granted. (OK, I know I just oversimplified a very complex set of processes - but the result is the same: the organization is deemed compliant or not)
But, what about the products that are used to support organizational PCI compliance? Network firewalls, antivirus, IDS/IPS, and application firewalls are listed in the PCI specification as core products whose functionality is required to obtain PCI compliance. Don't these products have to be certified as compliant? No, there is no provision for product compliance in the PCI DSS v1.1 specification.
So, given that PCI doesn't directly certify products, what should an organization do to provide audit assurance that products can be used for the intended PCI purpose?
- Verify vendor claims - just because a salesperson says it, it doesn't make the statement true.
- Rely on trusted third-parties - organizations like ICSA Labs, NSS Labs, WASC and OWASP have detailed product capability matrixes, testing and certification criteria, and comparative data.
- Discuss concerns with your auditors - because PCI auditors make the final decision on compliance, they should be involved in key decisions leading up to the certification event.
There have been some wild claims with PCI - including the notion of "PCI certified products." When faced with conflicting information, work with trusted vendors and partners, press your auditor or PCI QSA for the documented facts, and escalate ambiguity as necessary through to the PCI Security Standards Council.
With factual information and proper actions, we can all help PCI reach its lofty goal: Increase trust in credit card usage by holding merchants to a high standard - the PCI DSS.
PCI Backgrounder
PCI DSS, the Payment Card Industry Data Security Standard (or simply PCI) specifies compliance standards for credit card usage. If your organization stores, processes, or transmits credit card data, PCI applies to you. The PCI Security Standards Council maintains and publishes the standard at www.pcisecuritystandards.org.
*Note: There is a "Listing of PCI Security Standards Council Approved PIN Entry Devices" at: https://www.pcisecuritystandards.org/pin/pedapprovallist.html_. The PED's are the only products to have PCI SSC approval._
Looking back at the 2008 US RSA Security Conference, there was a tremendous amount of interaction, but not a readily apparent amount of innovation.
I spent the bulk of my time in meetings with customers, partners, press, and analysts. All seemed to echo the same sentiment - there's not any single "wow factor" at this year's RSA. But, that's not to say that there weren't hot topics, the two most obvious being DLP and Virtualization Security.
DLP
DLP, or Data Loss Prevention (also sometimes known as Data Leakage Prevention) is the capability to keep sensitive data from inadvertently leaving the organization. The concept and message around DLP is rather simple, but the architecture and management of DLP is where the difficulty comes into play.
When you consider all the sensitive data in most organizations, where it exists, and how it's used, you get a feel for just how big of a problem DLP needs to address. In most organizations, data isn't even regularly classified and labeled as public or non-public information. And, data has been over-distributed onto any media that can hold it (e.g. laptops, USB keys, iPods), often without any control. DLP technologies purport to get a handle around this problem and manage the access to and distribution of sensitive data.
On the surface, DLP seems like it's facing a really tough problem. And it is - if you're just trying to add controls to the existing model of data access and over-distribution. Looking at the problem with virtualization in your toolbox, though, can change our basic assumptions and bring us closer to the elusive goal of DLP.
Combining application virtualization and DLP allows authorized users to access a view of sensitive data, while providing additional context-sensitive controls around access to the data. As an example, a user in the office might be given the ability to use a data housing sensitive application on their corporate managed device only after submitting strong credentials and passing necessary security checks. A policy would prohibit them from using the application in ways that violate policy, such as printing sensitive info. Because the DLP software is integrated with the application virtualization environment in the data center, the DLP software has full control over usage of sensitive components data, and the data never leaves the datacenter. DLP can be much more effective when managed from the datacenter and the management of sensitive data on endpoints is eliminated from the equation. The same concept holds true for both application virtualization and desktop virtualization.
Virtualization Security
As the above DLP example shows, virtualization is stimulating innovative thoughts and challenging the status quo. There were many questions posed at RSA about upcoming client and desktop virtualization opportunities, in addition to current server virtualization security challenges.
On the server front, most of the discussions were around how network-level security objectives can be achieved in a virtual server environment. Organizations that have implemented server virtualization have watched as the proliferation of these environments have reduced security visibility for legacy network controls. The network folks want to know how to "see" into the virtual server environment, and how to control VM-VM communications. This is being accomplished for the most part through "security virtual appliances" or "security virtual machines" that duplicate physical network controls in the virtual realm. There appeared to be many vendors touting capabilities for scanning, IDS/IPS, and virtual firewalls with techniques borrowed from the physical realm.
The real breakthroughs appear to be just in front of us and will involve how we utilize virtual applications and desktops. The capability to virtualize and abstract for security isolation, as well as usability appear to be driving real change. These changes promise to allow user functionality to follow them anywhere, without cumbersome user configuration and management. And, with security policies built in, maintained and verified, we should see the trust models change for the better. Microsoft introduced some very interesting concepts and considerations around End-to-End Trust at the beginning of the show that extend well into virtualized client capabilities.
As the security industry matures, we'll probably witness less of a "wow" factor with each conference. But we'll all sleep a little better knowing we're getting closer to the goals of true security.
-
July 2008 Sun Mon Tue Wed Thu Fri Sat 1 2 3 4 56 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Search
-
Subscriptions
-
Group Blogs
-
Blogger Profile
-
Popular Tags
Most Viewed Posts
