Network Security in the Age of *Any* Computing: Policy Granularity

As we discussed in the last post, there are number of ways to enforce access policies for any computing. Given the flexibility and dynamic nature of business, access policies should provide sufficient flexibility to meet business needs. To illustrate, let’s look at how an enforcement mechanism like network access control (NAC) can provide this kind of granularity. What you want is map out access models and design a set of policies to provide users with the right access at the right time from the right device. Let’s focus on mobile devices, the poster children for any computing, and typically the hardest to secure. First we will define three general categories of mobile devices trying to connect to your network: Corporate devices: You have issued these devices to your employees and they are expected to get full access to pretty much whatever they need. You’ll want to verify both the user (strong authentication) and the device itself. It is also important to monitor what the device is doing to ensure authorized use after the pre-connect authentication. Personal devices: Sure, it’s easy to just implement a blanket policy of no personal devices. There are big companies doing that right now, regardless of user grumpiness over not being able to use their fancy new iPads at work. But if draconian isn’t an option in your shop, you could move authenticated, unauthorized devices onto a logical network configured only for outbound Internet access. Or provide access to non-critical resources such as employee wikis and the like but block access to corporate email servers, assuming you don’t want company email on these devices. Everything else: Lots of guests show up at your facilities and try to connect to your networks – both wired and wireless. If they successfully gain access via WPA2 or a physical port, they need to be bounced from the network. This represents the “access” part of network access control. Depending on your pain threshold, there are many other device types and usage models that can be profiled to create specific enforcement policies. Granularity is only limited by your ability to map use cases and design access policies. Let’s not forget that you can also implement policies based on roles. For instance, your marketing group might have network access with iPads, since every good marketer needs one. But if engineers do not have a business justification for iPad use that group could be blocked. Policies aren’t defined merely by what (device) the user has, but also on who they are. Posture-based Policies What about policies based on defenses implemented on the endpoint or mobile device – such as AV, full disk encryption, and remote wipe? Clearly you need to control those devices as well. Being able to restrict users without certain patches on their device is legitimate. Or you might want want to keep end users off of your protected network segment if they don’t have full disk encryption active, to avoid breach disclosure if they lose the device. It’s not just about knowing what the device is, and who is using it, but also what’s on it. As you can see, this is problem includes at least 3 dimensions, which is why getting policies right is a prerequisite for controlling access. We’ll talk more about getting the policies right incrementally when we wrap up the series. Which, once again, brings up our main point. Make sure you can enforce security policies that reflect your desired security posture given the context of your business processes. Don’t force your security policy to map to your enforcement mechanisms. Share:

Read Post

Table Stakes

This morning I published a column over at Dark Reading that kicked off some cool comments on Twitter. Since, you know, no one leaves blog comments anymore. The article is the upshot from various frustrations that have annoyed me lately. To be honest, I could have summarized the entire thing as “grow the f* up”. I’m just as tired of the “security is failing” garbage as I am with ridonkulous fake ROI models, our obsession with threats as the only important metric, and the inability of far too many security folks to recognize operational realities. Since I’m trying to be better about linking to major articles, here’s an excerpt: There’s been a lot of hand-wringing in the security community lately. Complaints about compliance, vendors and the industry, or the general short-sightedness of those we work for who define our programs based on the media and audit results. Now we whine about developers ignoring us, executives mandating support for iPads we can’t control (while we still use the patently-insecureable Windows XP) executives who don’t always agree with our priorities, or bad guys coming after us personally. We’re despondent over endless audit and assessment cycles, FUD, checklists, and half-baked products sold for fully-baked prices; with sales guys targeting our bosses to circumvent our veto. My response? Get over it. These are the table stakes folks, and if you aren’t up for the game here’s a dollar for the slot machines. Share:

Read Post

FAM: Market Drivers, Business Justifications, and Use Cases

Now that we have defined File Activity Monitoring it’s time to talk about why people are buying it, how it’s being used, and why you might want it. Market Drivers As I mentioned earlier the first time I saw FAM was when I dropped the acronym into the Data Security Lifecycle. Although some people were tossing the general idea around, there wasn’t a single product on the market. A few vendors were considering introducing something, but in conversations with users there clearly wasn’t market demand. This has changed dramatically over the past two years; due to a combination of indirect compliance needs, headline-driven security concerns, and gaps in existing security tools. Although the FAM market is completely nascent, interest is slowly growing as organizations look for better handles on their unstructured file repositories. We see three main market drivers: As an offshoot of compliance. Few regulations require continuous monitoring of user access to files, but quite a few require some level of audit of access control, particularly for sensitive files. As you’ll see later, most FAM tools also include entitlement assessment, and they monitor and clearly report on activity. We see some organizations consider FAM initially to help generate compliance reports, and later activate additional capabilities to improve security. Security concerns. The combination of APT-style attacks against sensitive data repositories, and headline-grabbing cases like Wikileaks, are driving clear interest in gaining control over file repositories. To increase visibility. Although few FAM deployments start with the goal of providing visibility into file usage, once a deployment starts it’s not uncommon use it to gain a better understanding of how files are used within the organization, even if this isn’t to meet a compliance or security need. FAM, like its cousin Database Activity Monitoring, typically starts as a smaller project to protect a highly sensitive repository and then grows to expand coverage as it proves its value. Since it isn’t generally required directly for compliance, we don’t expect the market to explode, but rather to grow steadily. Business Justifications If we turn around the market drivers, four key business justifications emerge for deployment of FAM: To meet a compliance obligation or reduce compliance costs. For example, to generate reports on who has access to sensitive information, or who accessed regulated files over a particular time period. To reduce the risk of major data breaches. While FAM can’t protect every file in the enterprise, it provides significant protection for the major file repositories that turn a self-constrained data breach into an unmitigated disaster. You’ll still lose files, but not necessarily the entire vault. To reduce file management costs. Even if you use document management systems, few tools provide as much insight into file usage as FAM. By tying usage, entitlements, and user/group activity to repositories and individual files; FAM enables robust analysis to support other document management initiatives such as consolidation. To support content discovery. Surprisingly; many content discovery tools (mostly Data Loss Prevention), and manual processes, struggle to identify file owners. FAM can use a combination of entitlement analysis and activity monitoring to help determine who owns each file. Example Use Cases By now you likely have a good idea how FAM can be used, but here are a few direct use cases: Company A deployed FAM to protect sensitive engineering documents from external attacks and insider abuse. They monitor the shared engineering file share and generate a security alert if more than 5 documents are accessed in less than 5 minutes; then block copying of the entire directory. A pharmaceutical company uses FAM to meet compliance requirements for drug studies. The tool generates a quarterly report of all access to study files and generates security alerts when IT administrators access files. Company C recently performed a large content discovery project to locate all regulated Personally Identifiable Information, but struggled to determine file owners. Their goal is to reduce sensitive data proliferation, but simple file permissions rarely indicate the file owner, which is needed before removing or consolidating data. With FAM they monitor the discovered files to determine the most common accessors – who are often the file owners. Company D has had problems with sales executives sucking down proprietary customer information before taking jobs with competitors. They use FAM to generate alerts based on both high-volume access and authorized users accessing older files they’ve never touched before. As you can see, the combination of tying users to activity, with the capability to generate alerts (or block) based on flexible use policies, makes FAM interesting. Imagine being able to kick off a security investigation based on a large amount of file access, or low-and-slow access by a service or administrative account. File Activity Monitoring vs. Data Loss Prevention The relationship between FAM and DLP is interesting. These two technologies are extremely complementary – so much that in one case (as of this writing) FAM is a feature of a DLP product – but they also achieve slightly different goals. The core value of DLP is its content analysis capabilities; the ability to dig into a file and understand the content inside. FAM, on the other hand, doesn’t necessarily need to know the contents of a file or repository to provide value. Certain access patterns themselves often indicate a security problem, and knowing the exact file contents isn’t always needed for compliance initiatives such as access auditing. FAM and DLP work extremely well together, but each provides plenty of value on its own. Share:

Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.