From bc26fb0d0f2ff6208d49008d9cbf7c644803f01b Mon Sep 17 00:00:00 2001 From: Ambg05 Date: Tue, 1 Nov 2016 16:19:39 +0000 Subject: [PATCH 1/5] Update Feedback-loops.md --- content/From-audio/To-Fix/Feedback-loops.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/From-audio/To-Fix/Feedback-loops.md b/content/From-audio/To-Fix/Feedback-loops.md index 21553d5..e77e284 100644 --- a/content/From-audio/To-Fix/Feedback-loops.md +++ b/content/From-audio/To-Fix/Feedback-loops.md @@ -1,15 +1,15 @@ ### Feedback Loops -Key to dev ops is feedback loops. The most effective and powerful dev ops environment are environments where feedback loops and monitoring and visualizations are not second class citizens. And the more faster you release the more understanding you need to have on what is happening. +The key to DevOps is feedback loops. The most effective and powerful DevOps environments are environments where feedback loops, monitoring, and visualizations are not second-class citizens. The faster you release, the more you need to understand what is happening. -So it is key to understand that dev ops it is not silver bullet, in fact anybody selling silver bullets, already selling snake oil. It is a profound transformation on how you build and develop software. +DevOps is not a silver bullet, and in fact anyone saying so is not to be trusted. DevOps are a profound transformation of how you build and develop software. -And it is all about small interactions and basically small development cycles and making sure that you never make big changes at any moment in time. So the feedback loop is very key because what you end up having is situations where you can react very quickly. +DevOps are all about small interactions, small development cycles, and making sure that you never make big changes at any given moment. The feedback loop is crucial to this because it enhances your understanding and allows you to react to situations very quickly. -The only way you can react quickly is if you have programmatically codified your infrastructure, your deployment, your tests, and what you really want is automation of your understanding, the automation of your tests. And the feedback loops that you get are the ones that really make this possible. +The only way you can react quickly is if you have programmatically codified your infrastructure, your deployment, and your tests. What you want is automation of your understanding, and of your tests. The feedback loops you get make this possible. -So the success stories of dev ops, all being about the companies who have been moved from waterfall style development very top down to in a way the more agile way of doing things or even teams that were doing agile but it wasn't working very well, to actually being able to ship quickly. +The success stories of DevOps are all about the companies who moved from waterfall style, top-down development, to a more agile way of doing things. The success of DevOps has also allowed teams that were agile but weren't working very well, to ship faster. -So I like the idea that you push as fast as you can to production, it is key to have the two pipelines as I mentioned in other place of the book where if you are codifying with specific patterns that you know, you go as fast as you can, if you are adding changes that introduce new patterns then you have to have a separate suite of tests instead of suite analysis which is different from the normal paths. +I like the idea of pushing as fast as possible to production. It is essential to have the two pipelines I mention elsewhere in the book, where, if you codify with specific patterns that you know, you go as fast as possible. If you add changes that introduce new patterns, then you must have a separate suite of tests, instead of suite analysis, which is different from the normal paths. -So it is the feedback loops that allows you to understand this, the feedback loops of understanding how you just modify your attack surface, how you just change how your application behaves, how you just change key parts of how everything works and those feedback loops are what allows you to do that. +The feedback loops allow you to understand this. The feedback loops allow you to understand how to modify your attack surface, how to change how your application behaves, and how to change key parts of how everything works. From 2d06939b2775068d28fa4fa487cdd6f62a0a10d6 Mon Sep 17 00:00:00 2001 From: Ambg05 Date: Tue, 1 Nov 2016 16:50:31 +0000 Subject: [PATCH 2/5] Update Good-managers-are-not-the-solution.md --- .../To-Fix/Good-managers-are-not-the-solution.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/From-audio/To-Fix/Good-managers-are-not-the-solution.md b/content/From-audio/To-Fix/Good-managers-are-not-the-solution.md index 442ade1..aa8dc36 100644 --- a/content/From-audio/To-Fix/Good-managers-are-not-the-solution.md +++ b/content/From-audio/To-Fix/Good-managers-are-not-the-solution.md @@ -1,13 +1,13 @@ -### Good Managers Are Not The Solution +### Good Managers are not the Solution -One comment that is made when we talk about risk and work flows and business owners making decisions about development and QA teams that don't write tests is the statement, if we had good managers we wouldn't have this problem. +When we talk about risk, workflows, business owners making decisions about development, and QA teams that don't write tests, we often hear the comment, "If we had good managers, we wouldn't have this problem". -The problem with that statement if you had good managers in a way you wouldn't have the problem, the problem would be solved. That is the wrong positioning because if you had good managers, you wouldn't have that problem because by definition they would be asking the right thing. +That statement implies that if you had good managers, you wouldn't have the problem, because good managers would solve the problem. That is the wrong approach to the statement. Rather, if you had good managers, you wouldn't have the problem, because good managers would ask the right questions before the problem even developed. -So the solution and all these work flows aren't designed for when you have a good manager, a manager that pushes testing, that demands good releases, demands every day releases, demands changes to be done straight away. +These workflows aren't designed for when you have a good manager, a manager who pushes testing, who demands good releases, who demands releases every day, or who demands changes to be made immediately. -That is not what we are talking about or this whole solution is not designed for, this whole solution is designed for in a way and I don't mean like the term but bad managers are not very knowledgeable managers or managers who are just totally focused on the short termness of business decisions without thinking or even taking to account the medium term consequences of their action which is to go back to that idea of pollution is the managers would say just ship it now and we will deal with the pollution later or we will deal with the consequences later. Just get it out to the market, with start-ups you even get sometimes that you know push it out or else we don't have a company. +These workflows are designed for bad managers (I use the term reluctantly). Bad managers are not knowledgeable, or they are exclusively focused on the short-term benefits of business decisions, without taking to account the medium-term consequences of the same decisions. This goes back to the idea of pollution, where the manager says "Just ship it now, and we will deal with the pollution later". With start-ups, sometimes managers will even say, "Push it out or we won't have a company". -So, the whole risk work flow, the whole idea of making people accountable is exactly to do with those situations, with the bad managers, the ones that are in a way causing the problem. +The risk workflow, and the whole idea of making people accountable is exactly because of these kinds of situations, where poor decisions by management can cause huge problems. -And here is how we want to empower developers, empower the technical guys on the ground who are writing code, who basically have a very good grasp of reality or understand the side effects, they are the ones that should be making a good number of technical decisions and have the time to spend on actually coding and understanding what is actually going on. +We want to empower developers, the technical guys who are writing code and have a very good grasp of reality and potential side effects. They are the ones who should make technical decisions, because they are the ones who spend their time coding, and they understand what is going on. From 689043ac1875c6952d22940561ee63379a89e44d Mon Sep 17 00:00:00 2001 From: Ambg05 Date: Tue, 1 Nov 2016 17:16:32 +0000 Subject: [PATCH 3/5] Update Horizontal-dev-ops.md --- content/From-audio/To-Fix/Horizontal-dev-ops.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/From-audio/To-Fix/Horizontal-dev-ops.md b/content/From-audio/To-Fix/Horizontal-dev-ops.md index b87b2b6..b51f6ec 100644 --- a/content/From-audio/To-Fix/Horizontal-dev-ops.md +++ b/content/From-audio/To-Fix/Horizontal-dev-ops.md @@ -1,7 +1,7 @@ -### Horizontal Dev Ops +### Horizontal DevOps -The best model I have seen in integrating dev ops in a company has been the creation of teams that basically span multiple groups. So it is the same thing as in a way the security champions group where instead of having a very top-down approach to the deployment of the operations where you create the central teams, create the standards and create the bills and create everything, and then you basically push it down, the best model I have seen is a team where the central dev op teams will hire dev ops or train actually dev ops engineers and then allocate them to each team. +The best model I have seen for integrating DevOps in a company is where teams are created that span multiple groups. Instead of having a top-down approach to the deployment of operations, where you create the central teams, the standards, the bills, etc., and then push it down, the central DevOps team hires or trains DevOps engineers and then allocates them to each team. -So the logic would be that each team gets a couple days a week or some time from that particular dev op engineer and his job is to ultimate those practices. The job is to actually embed the dev op activities and best practices into development life cycle. +The logic is that each team spends a certain amount of time with a DevOp engineer, who trains the teams in DevOp activities and best practices, and thereby embeds the best practices in the development life cycle. -So you end up having this horizontal teams which are great because in a way they have two masters, they answer to dev ops but they also answer to the team lead and they share best practices, they collaborate. And it is a much better way to scale and also it makes the teams want to collaborate because you know again you aren't saying spend all the time doing this, you are basically saying hey here is someone who is going to help you to do this. +The result is horizontal teams, which have several advantages. They have two masters: they answer to DevOps but they also answer to the team lead, and they share best practice. The creation of horizontal teams is a much better way to scale, and it encourages teams to collaborate. The teams know they aren't required to spend all their time working in DevOps, and they know there is someone who can help them. From f35c7715a0769157ab28127e14ab4397dfe2a1e5 Mon Sep 17 00:00:00 2001 From: Ambg05 Date: Wed, 2 Nov 2016 11:07:02 +0000 Subject: [PATCH 4/5] Update Is-the-decision-hyper-linked.md --- .../To-Fix/Is-the-decision-hyper-linked.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/From-audio/To-Fix/Is-the-decision-hyper-linked.md b/content/From-audio/To-Fix/Is-the-decision-hyper-linked.md index 22ba555..5e353df 100644 --- a/content/From-audio/To-Fix/Is-the-decision-hyper-linked.md +++ b/content/From-audio/To-Fix/Is-the-decision-hyper-linked.md @@ -1,13 +1,13 @@ -### Is The Decision Hyper Linked +### Is the Decision Hyperlinked? -I hear this over and over again- the manager knows about it, I told you about this in the meeting, everybody is aware of this e.t.c. If that decision is not in a hyperlink-able location that decision doesn't exist and it is key that you capture that. Because without a very clear track of those decisions, you cannot learn from experience, you cannot learn from being able to predict what is going to happen in the future. +I regularly hear the following statements: "The manager knows about it", "I told you about this in the meeting", "Everyone is aware of this", and so on. However, if a decision is not in a hyperlinkable location, then the decision doesn't exist. It is vital that you capture decisions, because without a very clear track of them, you cannot learn from experience. -And in a way the reason why that is important is not for the first scenario because it would always fail, it is the long game, it is the second and third situation where you want to start building the credibility to say, "we did this in the past, it didn't work here are the consequences, here is the real cost of that particular decision, let's not make this mistake again". +Capturing decisions is most important for the longer term. When you deal with your second and third situations, you start building the credibility to say, "We did this in the past, it didn't work then, and here are the consequences. Here is the real cost of that particular decision, so let's not repeat this mistake". -This is very important,it is very important to really be able to do postmortems and understand the real cost of decisions, understand that that comment that was made, "oh we don't have time to do this now because we have a deadline", six months later or after a huge amount of manpower and time spent in fixing the problem, you need to be able to say, "well actually was that decisions the correct one? Actually in a way we have said we can't do this because we don't have time actually let's now learn from that and really quantify what we are talking about". +It is essential to do postmortems and understand the real cost of decisions. If a comment is made along the lines of, "Oh, we don't have time to do this now because we have a deadline", after a huge amount of manpower and time has been spent fixing the problem, you need to be able to say, "Was that decision the correct one? Let's now learn from that, and really quantify what we are talking about". -Because for the future then next time you want to say, "well we need a week or two weeks or a month to do this", you could always say, "see last time we didn't do this and we lost six months". So it is very key that in a way not only do you capture the decisions, you then make sure you do very good postmortems on what happens after those risk being accepted. +Completing this exercise will give you the knowledge to say the next time, "We need a week, or two weeks, or a month to do this". Or you could say, "Last time we didn't do this and we lost six months". So, it is key not only to capture the decisions, but also to ensure you do a very good postmortem analysis of what happens after risks are accepted. -And another key concept is that when then there is the consequences or either security issues or the incidence on the problems of technical debt that exists because of one of these bad decisions is very key that it all gets hyper-linked back to the original issue. +When there are negative consequences because of a bad decision, such as security issues or problems of technical debt, it is important that the consequences are hyperlinked back to the original issue for future reference. -So in a way the original issues are the foundations of the business case of why that in a way was a problem and why you don't want to repeat it again in the future. +In a way, the original issues are the foundations of the business case for why a problem occurred, and why you don't want to repeat the problem in the future. From f374dcc2bac948e9995fa863b2187adc9cd155f5 Mon Sep 17 00:00:00 2001 From: Ambg05 Date: Wed, 2 Nov 2016 11:51:56 +0000 Subject: [PATCH 5/5] Update Security-champions-involved-in-decisions.md --- ...Security-champions-involved-in-decisions.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/content/From-audio/To-Fix/Security-champions-involved-in-decisions.md b/content/From-audio/To-Fix/Security-champions-involved-in-decisions.md index 842e77c..8113d32 100644 --- a/content/From-audio/To-Fix/Security-champions-involved-in-decisions.md +++ b/content/From-audio/To-Fix/Security-champions-involved-in-decisions.md @@ -1,15 +1,17 @@ -### Security Champions Involved In Decisions +### Involve Security Champions in Decision-making -One of the feedback you get from security champions once the program starts being placed is that they are not or they don't tend to be involved in sometimes the work flows and the decisions because a lot of teams those decisions are made outside the realm of developers so developers are very late on the food chain about those decisions. +Once a program starts being placed, security champions will often give feedback that they are not involved in the workflows and decisions. The job of the security champion is to ask, "What is this? Do I trust this? What happens with this?", but they often don't get the opportunity to ask these questions, because decisions are made without their input. -And that is a problem because in a way the job of the security champion starts to be to question, to ask, "what is this, do I trust this, what happens with this?" So a really good situation that happened recently was the security champion that basically started to do threat models across this product, and he basically managed to retroactively started to be involved in some of the decisions. +To illustrate this problem, a situation occurred recently where the security champion started to create threat models across a product, and thereby managed to retroactively involve himself in some of the decision-making. -And when he did a threat model with a lot of the developers and the other systems owners, they found a couple of end points that were really problematic. And it was actually once the teams started to be aware of, "Oh we shouldn't trust this", "oh that data isn't trusted" or "that could be a problem" then the developers themselves going, "oh actually hold on, what about this method?" +He created a threat model with a lot of the developers and the other systems owners, and they found a couple of end points that were problematic. Once the teams were aware of the problems, realizing that data wasn't trustworthy, and identifying vulnerabilities, then the developers themselves started to question the methods. -So they actually found a really nasty exposed method that actually nobody really knew the full story, but it was really powerful, you actually allowed quite a lot of data to be erased with very little accountability and it was a very toxic method. +They found a nasty, exposed method that nobody knew about. It was a powerful and toxic method, that allowed a lot of data to be erased with very little accountability. -And basically that method should never be there and it happened that it wasn't even validated, there were all sorts of other things that were missing, and it was basically a good example of the kind of things that you want the security champions to be involved because you want them to question those things before they go live before they actually hit even development, you want to catch them as early as possible. +That method should never have got there; it wasn't even validated, and there were other components missing. -So in a way it is not to say no to the functionality, it is not to say don't do this it is just to say, "well if you want to do this, here are the side effects, here are the compromises, here is basically how we should protect that" or at least to say, "hey you know, you are going to do this but we aren't giving a [inaudible 00:02:26] thing about security implications so here you go, accept the fact that this feature has no security thinking behind it". +This is exactly the kind of exercise you want security champions to be involved in, because you want them to question those things before they hit development, before they go live. You want to catch those problems as early as possible. -Which is something that is very hard for a project owner to accept, to say "hey the feature that you are pushing, we haven't considered the security implications, we have not considered the side effects of security on this feature which basically means that you are accountable for how it works", which basically makes those guys really uncomfortable. +This is not to say "No" to functionality. It is rather to say, "If you want to do this, here are the side effects, here are the compromises, and here is how we should protect it". At the very least you should say, "If you do this, you do it without due regard being given to the security implications. You must accept the fact that this feature has no security thinking behind it". + +It is very hard for a project owner to accept that the feature being pushed has not benefitted from the consideration of security implications and side effects. This leaves him accountable for how it works, and this makes project owners uncomfortable.