Project Quant: Database Security Planning

By Adrian Lane, Rich

This is the third post in our series on Project Quant for Database Security (see Part 1 & Part 2). The first step in our metrics process framework is to gather requirements and plan out your security program. Just as with any development project, your motivation and goals should be documented up front, and later used to gauge the success of your effort. Like most IT projects, gathering requirements is a large part of the work.

I want to clarify a couple points based on comments we have received to date, before I delve into planning. As Rich pointed out at the beginning of the previous post, database security is an incredibly broad subject, comprised of several specific elements. The original Project Quant for Patch Management focused on the nuances of a single IT task, whereas this database security project includes a minimum of four separate efforts. We originally planned to create a separate process for each effort: configuration management, auditing & monitoring, access control, and data protection. Heck, we even considered breaking down configuration management into smaller subtasks. When we dug in one afternoon to start identifying specific actions, we realized there was both a lot of overlap between our initial processes, and a number of important functions they missed. Instead, we came up with the generalized process framework we introduced in Part 2, with a series of sub-processes.

We know this won't exactly match everything you do, but as with Project Quant for Patch Management, we are proposing a generic framework that encompasses most possible activities, from which you can pick and choose to meet your own needs.

In Quant for Patch Management, we also found that a handful of the metrics accounted for the bulk of the costs. Some 30% did not have material impact on overall cost. Based on our initial research the same is true with database security, so we want to provide a lot more breadth in this series and focus on principal metrics, foregoing the level of detail we used in PQPM. We will mention these extra tasks in each phase, but leave it up to readers to include any additional cost metrics which are useful in their own analysis.

For the planning stage, we include Configuration, AAA, Monitoring, and Classification. Starting with Configuration Standards:

1. Identify Requirements: Requirements include everything from adopting database security best practices to PCI compliance. They may originate from external or internal sources. Requirements, especially for industry and regulatory compliance, are generic and require some interpretation. Directives such as "implement separation of duties" or "secure the database from SQL injection" are common. In other cases specific security advisories from CERT or patches from vendors are less ambiguous, but still require analysis to determine suitability. Identify sources of information and identify requirements appropriate to your situation, including vendor-provided security configuration guides, NIST, and the Center for Internet Security.
2. Develop Standards: Starting from security or compliance requirements, which portions are relevant to you? This is where you specify standards needed to satisfy requirements. Select settings, controls, and standards as necessary, pulling from the sources and matching your requirements.
3. Choose Implementation: Most database security functions can be accomplished in more than one way. For example, "capture failed logins" can be satisfied through external monitoring or internal auditing. Satisfying a requirement on Oracle may be accomplished differently than on SQL Server. Don't get bogged down into specifics, but select a strategy that meets you standard and fits your operational model.
4. Document: Record your findings and your decisions. If you are going through this process, odds are there are other people involved who will need to understand and adhere to the standard.

For many of you, you are probably saying to yourself "Holy @&!^@, just planning is a huge effort! Where do I begin?" Identifying requirements for database security or PCI or whatever is lengthy and complex, and it's not clear where to find this information. And I am being a hypocrite here, doing exactly what I have said you should not do and criticized others for: dropping a big, hairy task in your lap without pragmatic advice. While our focus in this project is identifying and quantifying costs to secure databases, we can't totally ignore what it takes to do the work, and we need to provide a some specific advice along the way. I will provide much more detail later in this series with use cases, but for now I can provide a couple pointers to steer you in the right direction.

Database configuration affects security as well as database function. For planning purposes you will be considering installation or removal of functions, network communications, platform versions, structures, use of underlying hardware or OS resources, physical location, and reliance on external programs/functions. All of these database functions are impacted by access control because appropriate use is determined by ownership and access, but we want to start with the basic capabilities and refine from there.

Start your effort by locating sources of information and standards bodies. What are others doing to meet security requirements? The database vendors are a good place to start, as they provide recommend setup and configuration, and list recent security notifications. Leverage security and operations personnel within your company to highlight security issues. Look to local DBA groups for advice on how they set up databases securely. As far as compliance, you can wade through the law doing your best to understand it, but if you have co-workers who specialize in audit and compliance, ask for assistance. If you company has security guidelines in place you are lucky, so use them to help scope the set of tasks. These are the steps many companies must perform, but research and discovery is a very large part of the process and typically an overlooked when costing.

I am going to keep this post short to encourage feedback on the general approach first. Rather than inundate you with details, I will cover the remaining three preparation steps in the next post.

–Adrian Lane, Rich

Project Quant: Database Security Process Framework

By Rich

Here's our first pass at a high-level process framework for Quant for Databases. Patch management is mostly a contiguous process cycle, but database security encompasses a bunch of different processes. This is a framework I originally used in my Pragmatic Database Security presentation (which I really need to go post now).

I realize this is a lot, but database security is a pretty broad topic -- from patch management, to auditing, to configuration, to encryption, to masking, to... you get the idea. We believe that the high level process framework presented here is intended to cover all these tasks. We could really use some feedback on how well this encompasses all the database security processes. We based this process on our own experience and research contacts, but want to know how you approach these job functions.

Our next step will be to roll through all the sub-processes within each of these major steps. We don't plan to get as detailed as we did with patch management. Many of the metrics provided in the original Quant project for patch management were extremely granular since we were dealing with only one process. We still need sufficient granularity to develop meaningful metrics that support process optimization, but at a level that's a little easier to collect, since we are covering a wider range of functions.

Please keep in mind that our philosophy is to build out a large framework with many options, which individual organizations can then pick and choose from. I know not everyone performs all these steps, but this is the best way to build something that works for organizations of different sizes and verticals.

Plan

In this phase we establish our standards and policies to guide the rest of the program. This isn't a one-time event, since technology and business needs change over time. Standards and policies should be considered for multiple audiences and external requirements.

1. Configuration Standards: Develop security and configuration standards for all supported database platforms.
2. Classification Policies: Set policies for how data will be classified. Note that we aren't saying you need complex data classification, but you do need to establish general policies about the importance of different kinds of data (e.g., PCI related, PII, health information) to properly define security and monitoring requirements.
3. Authentication, Authorization, and Access Control Policies: Policies around user management and use of accounts -- including connection mechanisms, DBA account policies, DB vs. domain vs. local system accounts, and so on.
4. Monitoring Policies: Develop security auditing and monitoring policies, which are often closely tied to compliance requirements.

Discover and Assess

In this phase we enumerate (find) our databases, determine what applications use them, what data they contain, and who owns the system and data; then assess the databases for vulnerabilities and secure configurations. One of the more difficult problems in database security is finding and assessing all the databases in the first place.

1. Enumerate databases: Find all the databases in your environment. Determine which are relevant to your task.
2. Identify applications, owners, and data: Determine who is responsible for the databases, which applications rely on them, and what data they store. One of your primary goals here is to use the application and data to classify the database by importance and sensitivity of information.
3. Assess vulnerabilities and configurations: Perform a configuration and vulnerability assessment on the databases.

Secure

Based on the results of our configuration and vulnerability assessments, we update and secure the databases. We also lock down access channels and look for any entitlement (user access) issues. All of these requirements may vary based on the policies and standards defined in the Plan phase.

1. Patch: Update the database and host platform to the latest security patch level.
2. Configure: Securely configure the database in accordance with your configuration standards. This also includes ensuring the host platform meets security configuration requirements.
3. Restrict access: Lock down access channels (e.g., review ODBC connections, ensure communications are encrypted), and check user entitlements for any problems, such as default administrative accounts, orphan accounts, or users with excessive privileges.
4. Shield: Many databases have their own network security requirements, such as firewalls or VPNs. Although directly managing firewalls is outside the domain of a database security program, you should still engage with network security to make sure systems are properly protected.

Monitor

This phase consists of database activity monitoring and database auditing. We'll detail the differences later (you can up on them in the Research Library), but monitoring tends to be focused on granular user activity, while auditing is more concerned with traditional audit logs. Both of these tie into our policies from the Plan phase and vary greatly based on the database involved.

1. Database Activity Monitoring: Granular monitoring of database user activity.
2. Auditing: Collection, management, and evaluation of database, system, and network audit logs (as relevant to the database).

Protect

In this phase we apply preventative controls to protect the data as users and systems interact with it. It includes using Database Activity Monitoring for active alerting, encryption, data masking for data moved to development, and Web Application Firewalls to limit database attacks via web applications.

1. Database Activity Monitoring: In the Monitor phase we use DAM to track activity, in this phase we create active policies to generate alerts on violations or even block activity.
2. Encryption: Activities to support and maintain encryption/decryption of database data.
3. Data masking: Conversion of production data into less sensitive test data for use in development environments.
4. Web Application Firewalls: Since many database breaches result from web application attacks, typically SQL injection, we've included WAFs to block those attacks. WAFs are one of the only post-application-deployment tools available to directly address database attacks at the application level. (We considered adding additional application security options, but aside from secure development practices, which are well beyond the scope of this project, WAFs are pretty much the only tool designed to actively protect the database.)

Manage

The triumvirate of ongoing systems and application management -- configuration management, patch management, and change management.

1. Configuration management: Keeping systems up to date with configuration standards... including standards that change over time due to new requirements.
2. Patch management: Keeping systems up to date with the latest patches.
3. Change management: Databases updates on a regular basis; including structural/schema changes, data cleansing, and so on.

Yes -- that's a whole heck of a lot of territory to cover, which is why I stayed fairly terse in this post. In talking with Adrian (who is co-leading this project) we think most organizations lump this activity into 3 buckets/sub-processes:

1. Normal database management activities: primarily configuration and patch management -- typically managed by database administrators.
2. Database assessment.
3. Monitoring and auditing.

No, that doesn't capture everything in the main process, but that's how most organizations which have database security programs break things out. We have simplified the tasks at the high level, but requirements and policies may come from groups external to database operations -- such such as security, privacy, audit, and compliance. If you are a DBA reading this overview process, you could go through this exercise to build out your cost model for simple operations very quickly. The model will hopefully scale just as well for organizations with more complex systems, but will take longer to account for all of your requirements.

This brings up two big questions we could use some help with:

1. Does the structure work? You'll notice I didn't list this out as one straight process, but as a series of ongoing, overlapping, and related processes.
2. Are we missing anything? Should we move anything? Insert, update or delete?

Thanks... in our next posts we're going to start walking through the model and detailing all the sub-processes so we can come back to them and build out the metrics.

–Rich

An Open Metrics Model for Database Security: Project Quant for Databases

By Rich

One of the more vexing problems in information security is our lack of metrics models for measuring and optimizing security efforts. We tend to lack frameworks and metrics to help measure the efficiency and effectiveness of security programs. This makes it more difficult both to improve our processes, and to communicate our value to non-technical decision makers.

I'm not saying we don't have any metrics. In recent years we've come a long way, with developments such as the Center for Internet Security's Consensus Metrics and the work of Andrew Jaquith and the Security Metrics community. For the most part these metrics fall into two broad categories: program metrics, and risk/threat models.

One area that has been generally lacking -- not to take anything away from the other two categories -- is detailed process-oriented models for improving efficiency and effectiveness within specific security areas. In other words, instead of just determining whether a particular process is an overall improvement, such as by measuring time to patch managed systems (efficiency) or percentage of overall systems patched (effectiveness), we lack tools for examining the individual steps within the process for finer-grained changes. Such detailed measurements can help us figure out how much it costs to patch, identify where and why our patching might be slower than desired (and thus how to make it faster), and determine why certain systems fall between the gaps and aren't patched. Our higher-level models help us evaluate risk and overall security programs, while detailed metrics would be useful for performance optimization.

Our first attempt at building a security performance optimization model focused on patch management, and we called it Project Quant. Over about 6 months we built a standard process framework for patch management, with heavy community participation, and then identified a series of detailed metrics for each step in the process. We ended up with about 40 steps in 10 min phases, with well over 100 potential metrics, prioritized so you can focus on few key areas because few people have the resources to measure them all.

About a month ago we were approached by a database security vendor to see if we could do the same thing for database security. This vendor, Application Security Inc., wanted an open, public, objective framework to measure the potential costs associated with database security. As with the initial Project Quant, which was sponsored by Microsoft, we agreed to proceed with the project as long as we could maintain our Totally Transparent Research policy. In other words, all the work has to be done in public, and the sponsor must participate through the same public mechanisms (comments and forum posts) as anyone else.

This project aligns very well with our research coverage, and we've been looking for an excuse to build out more-detailed database security process models for some time now. We also realized the format we used for Project Quant works well for other process-based metrics models. Thus we're proud to introduce Project Quant for Database Security, and we will now refer to the initial project as Project Quant for Patch Management.

Based on what we have learned to date in Project Quant, this is how the project will proceed:

1. We will, with community involvement, build out a high-level process framework for database security (see the patch management cycle for an example).
2. Once the high level process looks good, we will build out detailed steps for each phase of the higher-level process, and solicit public feedback and involvement.
3. We will build out sub-phase processes that help define tasks, and identify metrics for each step. Metrics will be hard costs in dollars (hardware/software), or time to complete the step. In some cases we will also include some effectiveness metrics (e.g., success vs. failure rates), but the primary focus of the model is costs/efficiency.
4. We will classify the metrics by importance and identify key metrics. We learned in the first Project Quant that it's easy to identify a large number of potential metrics, but most people need only focus on a few that they can measure with a reasonable investment -- once again, some metrics are expensive enough to measure that they would be a poor investment for some (or even most) organizations.
5. Where possible, we will support the research with open surveys and interviews.
6. Absolutely all the research will be conducted out in the open to maintain objectivity. All public comments will be retained as part of the project record, and no comments will be filtered except for spam and off-topic content. The sponsor is only allowed to participate through the same public mechanisms, so their financial involvement can't influence the result. (As with all our contracts, the sponsor doesn't have to pay if the result doesn't meet their needs due to our objectivity requirements).
7. Anyone can participate -- other security vendors, database and security professionals, database vendors, or anyone with too much time on their hands. If you work for a database or database security vendor, we ask that you disclose the company you are with.
8. All materials will be released under a Creative Commons license.

Since database security is more diverse than patch management, we expect to identify multiple sub-processes as part of an overall program. For example, assessment and monitoring aren't necessarily part of a contiguous cycle like most of the phases of patch management. Because this scope is also wider, we don't plan on delving into the same level of detail on the metrics as we did with patch management. To be honest, we probably went too deep, and included far more metrics than anyone could reasonably collect using current technologies.

In terms of timeline we are shooting to complete this project around the end of January or early February.

So let us know what you think. We'll start posting initial thoughts on the process model tomorrow, and start cranking through it from there. We'll keep all material in the Project Quant site, and will update the Research Library to reflect that we're now expanding Quant into other security areas.

Thanks,

–Rich

Raw Project Quant Survey Results

By Rich

At long last we are releasing the full results from the Project Quant survey. There are three files in the linked .zip: a summary .xls (with embedded charts), as well as the full results in .xls and .cvs formats.

We have 123 results so far, and plan on keeping the survey open indefinitely, releasing ongoing results as we get them. Based on the demographics, although we only hit 123 responses, we are very happy with the overall quality of the survey (there are a few obvious trolling attempts, but nothing material).

Click here for the full, raw survey results.

And don't forget, you can access the project report and survey analysis and take the survey.

–Rich

Project Quant Version 1.0 Report and Survey Results

By Rich

It's been a long few months, but I'm excited to finally announce the release of version 1.0 of the Project Quant model and report. We are also releasing our first pass at the analysis of the Project Quant survey, which included 100 responses at the time of analysis.

We really do consider this a 1.0 version of the model, and expect it to change as we get additional feedback and continue to explore the model with additional surveys, focused interviews, and other research. Please drop us any feedback here or in the forums.

The main report includes:

• Background material, assumptions, and research process overview.
• The complete Patch Management Process framework.
• The detailed metrics, which correlate with the process framework.
• Identification of key metrics.
• How to use the model.
• A lightweight version of the model, for those who don't need the full, detailed metrics.

This version currently lacks sample use cases, and we plan on releasing those as the project continues (at 45 pages, we felt it was already long enough). We also haven't finished the spreadsheet version of the model, and will get that out next week.

We are also releasing our first analysis report of the Project Quant open patch management survey. Due to time pressures stemming from Black Hat, we aren't able to release the raw survey results, but will get those up next week after we return from the conference. And don't forget, the survey is still live and we will continue to release results as we get them.

We've linked to the landing pages for both documents, since that's where we will be putting updates and supplemental material (hopefully you aren't annoyed by having to click 1 extra time to see the report). The material is being released under a Creative Commons license.

Finally, I still need to release the rest of our project communications, which are all sitting in a folder, but that too will have to wait until I get back from Black Hat.

We'd really like to thank the community of people who participated in the project, and we hope you will all continue to participate as we refine the model and advance the work.

Click here for the Project Quant survey analysis

Click here for the Project Quant Report

–Rich

Project Quant: Partial Draft Report

By Rich

We are pretty close to the end of the first phase of Project Quant, and I'm cramming away on finishing off the final report. Rather than throwing it out there in full final form, I'm going to post draft revisions every few days as I complete the report.

In other words, this isn't even close to final! The attached document is only about 50-60% of the report, but if any of you have spare cycles I could definitely use your opinions.

Here's what's in this one:

• Most of the introduction and context setting.
• An overview of the patch management cycle.
• Detailed steps for each of the patch management phases.
• A couple of survey results.

Here's what's not in the document:

• The detailed metrics themselves.
• Identification of key metrics.
• Conclusion.
• Credits for community participants.

I was also originally hoping we might have a fully functional spreadsheet tool, but since we ended up having to put a lot more work into formalizing a patch management project than expected, that ended up getting dropped.

Click here for the draft report

Eventually I'll post everything in a variety of open and editable formats, but while I'm cramming away on drafts I'll just be posting PDFs.

Thanks,

–Rich

Mid-Project Update and Trip Report

By Rich

The week before last I headed up to Microsoft to present a mid-term report on Project Quant.

I was up there for the better part of two days, and mostly gave the attached presentation to internal teams so they had an idea of what we've been working on. It also allowed me to get some face-to-face feedback on the project. As much as I'm a virtual kind of guy, every now and then it's good to throw your ideas in front of a live audience.

In keeping with out transparent research process, here's a quick summary of some of the feedback I received:

• The model doesn't currently account for predictability or maintenance windows. (While Microsoft obviously is a bit invested in patch predictability, I don't consider this an MS-specific bias). I'm struggling to figure out how to incorporate this into the model with "hard" metrics, since downtime or disruption isn't always the easiest thing to measure until it happens. I suspect that's how we'll have to include it in the model, but am open to better ideas.
• The model doesn't currently account for extended-support programs where an end-user requests a specific patch from their vendor. A variety of vendors offer this for post-support and/or specialized products, and it's very common even in mid-sized organizations (depending on vertical).
• The model doesn't incorporate feedback to the vendor on patches -- e.g., for bad patches or improper documentation.
• There are other organizations we should look at contacting to get more community involvement (I lost my copy of the list, so can't post it here -- one was the Security Leader's LinkedIn group, which I am a member of -- I sent them a message to last week).
• The initial survey results are very interesting -- especially since it looks like some of the weakest areas of patching are aligned with the highest growth areas of attack (e.g., desktop applications).
• The model doesn't account for the costs of not patching. I think we will have to be very clear that that isn't the purpose of this model, and additional risk analysis is better suited for those costs. On the other hand, that opens up the model to be misused to state that patching provides no benefit. I'm open to ideas on this one, so long as they are hard metrics we can really measure. Perhaps I'm just not being creative enough.

Those were the major points (I wasn't keeping notes). Most of the discussion was around the survey results and the top level structure of the model.

Since that visit, we are at 76 survey responses and I've posted all of the detailed phases of the patch management process.

So if you are curious to see what I presented, take a look:

ProjectQuantUpdate.pdf

And don't forget to fill out the Open Patch Management Survey!

–Rich

Project Quant: Document and Update Configuration Changes

By Rich

In the age of compliance, the job isn't finished until it's fully documented. Okay, that's probably always been true, but you are talking to a guy who got a D in FORTRAN because, despite completing all my programming assignments, I sort of never documented them (50% of the grade).

There are two kinds of documentation in this phase:

• Documenting the successful patch deployment (that systems are patched and up to date).
• Documenting any configuration standard changes.

As with all the other phases, this is merely my first attempt and it could use feedback.

This also concludes all the detailed steps of the various phases of the patch management cycle. Our next step is to convert this into the metrics model, and I expect a fair bit may change in that process.

–Rich

Project Quant: Clean Up Phase

By Rich

We might need to adjust the name for this phase, since we also have "clean up" as part of the deploy phase, but I think it does a reasonable job of representing the issues around redeploying failed updates. This isn't just a time to push out failed updates again, but to figure out why an update failed and any changes required to achieve a successful patch. Back in my operational days this was one of the more frustrating aspects of patch deployment. Most of the time patching went fairly smoothly, but those exceptions could double the amount of time we spent getting any particular update out to the entire organization.

I'm also curious as to what failure rate people see in the reports from their patch management tools. As you'll see when I load up some of the preliminary survey results, most organizations confirm successful patch deployment based on reports from the patch management tool. But in my humble experience, not all tools are completely accurate in confirming a successful deployment -- actually, most have some sort of error rate. Without some additional tool, such as vulnerability management, this could lead to 'stealth' unpatched systems.

Anyway, more on that later, and here's my first stab at detailing out the clean up phase:

–Rich

Project Quant: Confirm Deployment Phase

By Rich

The goal in this phase is to determine that patches successfully deployed.

I suspect the variables will change a bit as we convert this one into the quantitative model. Based on the initial survey results, organizations use a ton of different techniques to confirm successful patch deployments, and any single organization uses various techniques for different platforms.

Notice that we are testing both successful deployment, and successful functioning of the patch. Again, I realize not all organizations consistently test for both, but we are trying to include all possible options in the model.

–Rich

Project Quant: Deploy Phase

By Rich

Yep, today is a Quant two-fer as we continue to roll through and detail out the model.

The deployment phase seems pretty straightforward -- you prep a target, deploy the patch to it, install the patch, then clean up the deployment package/patch/other detritus (we'll cover confirming deployment and cleaning up problems in the next two phases).

This is the phase where the degree of your automation will likely have the greatest impact. I tried to account for issues like bandwidth by adding in the time to distribute the patch/deployment package. One thing this isn't capturing yet is the downtime associated with installing a patch, and the impact of patching in or out of maintenance windows. I'm thinking that will figure in as a separate metric outside the phases of the cycle itself.

Again, please let me know how this fits with what you are doing out there. To be honest this is more in-depth than our processes back when I was responsible for patching, but I won't claim we were the most mature organization in the world.

–Rich

Project Quant: Create and Test Deployment Package

By Rich

Okay, these steps in the middle of the patch management process are definitely more difficult to map out.

Here's my first pass at the steps to create and test deployment packages. I broke it out into:

• Identifying the right deployment tool (which may be "none/manual").
• Consolidating patches (since any single package might contain a number of patches).
• Building the deployment package.
• Testing to make sure it will deploy.
• Testing to make sure it works after being deployed.
• Getting approval to push it out.

Click here for the image

Please let me know how this matches to your own processes. I realize it will vary a lot based on what platform and tools are involved, so take this as a generic pass we can use to build out cost metrics.

–Rich

Project Quant: Test and Approve Phase

By Rich

Last week I spent a couple days up at Redmond presenting our work-to-date on Project Quant, and it was great to get some face to face feedback. I'll be posting a trip report (probably tomorrow) with the presentation I used and the feedback we received. Although we haven't reached 100 responses yet, the preliminary survey results are very interesting and we included some highlights in the presentation. (Please don't forget to take the survey).

But first I want to push out the next detailed phase in the cycle: Test and Approve. It's been a long time since I've been responsible for testing patches myself (and where I worked we were pretty immature about it), so this one could use more review than some of the other sections.

From my thinking, the biggest factor for any given test will be the number of test cases/dependencies. As I put the model together I'm realizing that some of these numbers won't be predictable if you haven't already measured them, and may not apply to "new" cases. For example, you can't know how long a given test for a given asset will take until you try it, although I suspect we will see some sort of predictability emerge based on trends. Also, there's another sub-cycle as tests either fail or produce other unwanted results.

In other words, this model isn't fully predictive, and is more oriented towards measuring what you currently do and tracking that over time. Then I think some predictive elements will emerge once you have a good base of metrics to work off. That should help those of you who try to use the model to help optimize your processes.

Just some rough thoughts that are a little out of scope of the details of this particular phase, but I think it's important to keep the context in mind as we build it out so we don't drift off course.

–Rich

Project Quant: Prioritize and Schedule Phase

By Rich

Yes folks, it's time for yet more patch management goodness!

Since our goal in Project Quant is to complete a first draft here by late June/July, I'm going to be posting all the draft phases of the cycle over the next week or so. As I've mentioned before, our goal here is to identify the steps of each patch management cycle phase, with any associated cost variables.

I felt a bit like I was drawing at straws to get into the details on this one, since the times & costs involved are pretty straightforward. You have to go through a prioritization exercise, match that to assets, then develop a schedule.

I think the main variables here are around the quality of your asset lists, patch and asset documentation, and so on. In other words, if you don't have a list of assets by value, it makes it harder to develop a prioritized schedule. If you don't have a lot of asset types or assets covered by the patch, you'll need more time.

Seems straightforward to me, but let me know what you think. Part of me wonders if we need to add a "meeting factor" for all the time many organizations waste trying to pull everyone together to agree on patch priorities. Seriously, we all know that can consume half or more of the time needed to schedule.

–Rich

Patch Management: Fixed (Non-Process) Costs

By Rich

In working on Project Quant and assigning variables to the patch management process phases, I realized there are certain fixed costs that aren't necessarily tied to a specific phase of the project. For example:

• Any patch management tools costs.
• Configuration or vulnerability management tools costs.
• Software maintenance licenses (since some platforms require a support contract to get patches).
• Patch tracking tool/service costs (for third party tools/services, when not part of the patch management tool).

These are just a few off the top of my head -- any other ideas? Remember, this is for costs not necessarily tied completely to any single phase of the patch management process.

–Rich