Securosis

Research

Implementing and Managing Patch and Configuration Management: Preparation

As we described in the Introduction to Implementing and Managing Patch and Configuration Management, endpoint hygiene is key to endpoint security management. WIth the product (or service) in hand, it’s time to get the technology implemented and providing value as quickly as possible. You know the old saying, “if you fail to prepare, you prepare to fail.” It’s actually true, and the preparation in this situation involves ensuring your processes are solid, defining device coverage and roll-out priorities, figuring out what’s already out there, and finally going through a testing phase to make sure you are ready to deploy widely. So, let’s revisit the patch and configuration management processes. Determine Processes We are process centric at Securosis. We admit it, but only because we understand the folly of trying to implement and manage technology without proper processes and accountabilities defined before products get installed. So we start most activities with a check to ensure the process supports the problem to be solved. With patch and configuration management, you are looking at two distinct but tightly intertwined processes. To be clear, you don’t have to do all the functions described below. Figure out which will work for your organization. But you do need to make sure everyone understands what they are supposed to do – especially when it comes to remediation. If the operations team is expected to run through the patch process, open up the maintenance windows, and confirm the successful implementation of each patch, they need to know that. Likewise, if the incident response team needs to investigate strange configuration changes found during assessment, the handoffs must be clearly defined, as well as your ability to remediate a device under investigation. Patch Management Discover and define targets: Before you jump into the Patch Management process you need to define which devices will be included. Is it just endpoints, or do you also need to patch servers? These days you also need to think about cloud instances. The technology is largely the same, but increased numbers of devices make execution more challenging. Obtain patches: You need to monitor for release of relevant patches, and then figure out whether you need each patch, or you can work around the issue. Prepare to patch: Once the patch is obtained you need to figure out how critical the issue is. Is it something you need to fix right now? Can it wait for the next maintenance window? Once priority is established give the patch a final Q/A check to ensure it won’t break anything important. Deploy the patch: Once preparation is complete and your window has arrived, you can install. Confirm the patch: Patches don’t help if the install fails, so confirm that each patch is fully installed. Reporting: Compliance requirements for timely patching make reporting an integral function. Obviously this is a very high-level process description. If you want a much more granular process map for patch management, with metrics and cost models, check out Patch Management Quant. Configuration Management Establish configuration baselines and/or benchmarks: First define acceptable secure configurations for each managed device type. Many organizations start with benchmarks from CIS or NIST (PDF) for granular guidance on how devices should be configured. Discover and define targets: Next find the devices that need to be managed. Ideally you can leverage an endpoint security management platform with an integrated asset management repository. You will also want to categorize and group assets to avoid unnecessary services. Engineering workstations, for example, require different configurations than Finance systems. Assess, alert, and report changes: Once devices are discovered and categorized, define a frequency for assessments. How often will you check them against policy? Some vendors use the term “continuous assessment”, but their assessments aren’t really continuous. Fortunately this isn’t normally a problem – not least because most operational groups wouldn’t be able to validate alerts and correct issues in real time anyway. Remediate: Once a problem is identified, either it needs to be fixed or someone needs to grant an exception. You are likely to have too much work to handle it all immediately so prioritization is key. We offered some perspective on prioritization for vulnerability management, but the concepts are the same for configuration management. You will also probably need to verify that changes actually took place for the audit, as well as plan for a roll-back in case the change breaks something. Define Initial Priorities/Targets and Deployment Model After gaining consensus on the applicable processes and ensuring everyone knows their roles and responsibilities, it’s time to determine your initial priorities/targets to figure out whether you will start with the Quick Wins process or jump right into Full Deployment. Most organizations have at least a vague sense of what types of devices they need to patch and manage, but translating that into deployment priorities can be tricky. Let’s highlight some of the categories of things you can manage, which should help you figure out the best direction. Servers: (OS) Keeping server devices updated is essential for protecting them. Look to group servers logically based on function, so you can identify typical configurations and applicable patch windows for each class of device. Also factor in whether you are dealing with physical servers, private cloud instances, or public cloud instances, because managing each type differs dramatically. PCs: (OS) Though non-server PCs are rarely the ultimate target of an attack, they provide a way for attackers to gain a foothold within your organization, so they can jump laterally to attack servers. Group PCs logically based on job function and need for access to critical data stores. Keep in mind that laptops create unique problems for to patch and configuration management because they may connect to the network infrequently, so consider whether you want to tackle that as part of the initial deployment. Mobile devices: (OS) Quicker than you can say BYOD, you will need to more effectively manage the mobile devices (including smartphones) that access your network. The smartphone vendors provide utilities to update and enforce configuration policies

Share:
Read Post
dinosaur-sidebar

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.