Risk avoidance usually means something different than the meaning you are trying to impart. Yes, it could mean doing something that increases risk over the long run, given that interpretation. But, risk is not a zero sum game. There are often ways to avoid risk without taking on longer term risks. Take investments, for instance. You can invest in risky securities and either hit it big or lose everything. Or you can not invest in non-risky investments like sticking with solid divident paying investments or bonds with very low risk. This is the kind of risk avoidance that documents like this are generally referring to. Actuarial sciences are often used to help quantify these. Sometimes risk is totally avoidable, sometimes it is minimized with mitigation controls and planned event triggers, and sometimes you might just have to roll the dice.
On Thu, May 15, 2014 at 10:09 AM, Tom Limoncelli <[email protected]> wrote: > On Thu, May 15, 2014 at 12:57 AM, Carolyn Rowland <[email protected]>wrote: > >> I would be interested in perspectives on this document if anyone takes >> the time to read the draft. >> > > It is a large document, so I'm really just skimming it. I have 2 comments: > > *2.3.4 Security Risk Management * > > This discusses ways to deal with risk: Avoid, Accept, Mitigate, Transfer. > > It has a very old-fashioned view of risk. That said, it would be good if > it could work in the fact that avoiding risk increases risk over time > because we get out of practice on how to handle the situation. For example > I know a place where an outage happened during an upgrade. The developers > said, "ok, we'll upgrade as rarely as possible!". The wise management > instead said, "No, we're going to require weekly releases until you can do > it without fail." 2-3 months later the upgrade process was mostly and > everyone on the team had experience doing it. The risk was future outages > was removed. > > I realize that 2.3.4 is describing a different kind of risk, but I'm sure > there is some kind of analog can be found. > > > *Chapter 3: Lifecycle* > > This section is very complete on the topics it covers but it skips the > most important part of a system's lifecycle: upgrades. > > The Heartbleed event was a stark reminder that one of the most important > parts of security is the ability to confidently upgrade a system rapidly > and frequently. When Heartbleed was announced, most people were faced with > the following fears: Fear that an upgrade would break something. Fear that > it wasn't well-understood how to upgrade something. Fear that the vendor > didn't have an upgrade for something. How many people were told, "Gosh, > the last time we upgraded (that system) it didn't go well so we've been > avoiding it ever since!" > > If an enemy really wanted to destroy the security of the systems that NIST > wants to protect, all he has to do is convince everyone to stop upgrading > the software. > > This chapter is about CREATING CREATING CREATING (upgrading) AND DISPOSAL > of the system. It should be about creating UPGRADING UPGRADING UPGRADING > and disposal of the system. > > Upgrading a system doesn't happen by accident. It requires planning from > the start. Each of the 11 phases documented in Chapter 3 should encourage > making future upgrades seamless. To be specific, upgrades should be rapid > (fast to happen once they've begun), frequent (happen periodically), and > promptly (low lead-time between when a vulnerability is published and when > the upgrade can start). > > 1. Stakeholder Requirements Definition: Should include "non-functional > requirements" (http://en.wikipedia.org/wiki/Non-functional_requirement) > including the ability to do upgrades rapidly, frequently, and promptly. > 2. Requirements Analysis: Should include measuring the > rapid/frequent/promptness of upgrades. > 3. Architectural Design: Some designs are easier to upgrade than others. > For example SOA architectures are easier to upgrade than monolithic > systems. Firmware is easier to upgrade than ROMs. > ... > etc. > ... > > The section should also include a discussion of the "smaller batches" > principle. If we do upgrades once a year, the changes in that upgrade is a > long, long list. (a large batch). If something breaks, we do not know > which change caused the problem. If we do upgrades frequently, the > "smaller batches" of changes means we can identify problems easier. > Ideally an upgrade happens after each change, thus we can pinpoint the > problem immediately. While this frequency may sound unrealistic, many > systems are now designed that way. For example Etsy has documented their > success with this system (and other companies will soon be publishing > similar reports). > > Related to my point about 2.3.4, upgrades are a risk that is mitigated by > NOT avoiding, but by doing it more frequently. The smaller batches > principle demonstrates that, as does the fact that when people do upgrades > more frequently they develop skills around it, see more opportunities to > optimize the process, and generally automate the process. Lastly it > reduces what I consider to be the single biggest security hole in any > system: lead time before a fix can be installed. > > > Carolyn, do you > Tom > > -- > Email: [email protected] Work: [email protected] > Skype: YesThatTom > Blog: http://EverythingSysadmin.com > > > > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/ > >
_______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
