Agile Security

I recently helped SANS review curriculum for an exciting new course coming out soon on a topic near and dear to my heart. While reviewing this course I started thinking about how security processes might evolve. I've often thought about the term Agile Security but not sure people would buy into this idea. It could be a great time for security teams to revisit how they operate. It could be the evolution of the cloud is driving the need to reconsider security perspectives. If what you are doing works just fine then don't change a thing. However, if you find the need to move faster and respond to threats more quickly, consider the following.

Agile: A word that makes some software engineers cringe because use of the word has transformed - like many other abused and overused words in the technical space by consultants and people jumping on bandwagons to sell products and services. But agile as a word is not the problem. It's the people who are talking about agile but doing quite the opposite. Agile just means you have a process that gets out of the way so you can work fast and adjust your plans quickly as your needs change. This is most important in a security environment with 0-days and rapidly evolving threats to organizations. 

Consider the transformation that occurred in the software industry. When I got my master’s degree in software engineering I took classes with and from people who worked at Boeing. We discussed how to write lengthy, detailed requirements documents with very precise numbered hierarchies. The document would cover every single implementation detail. In theory, this very thorough coverage of the requirements would save money.

Of course, when building something like an airplane details are crucially important. Lives are at stake. The same would apply for medical devices and software. But we were writing similar documents for internal business applications and web sites at the time. Companies would charge sometimes millions of dollars to spend three months or longer writing "Requirements Specifications".

In the end...when the programmers got the specifications, they didn't really work as planned and threw most of the spec out the window by the end of the project. Or worse, the developers followed the specifications precisely even though they didn't meet the need or solve the problem. Often the team would stumble upon information not known at the time of writing the requirements and would find that certain aspects of the requirements were not technically feasible or cost-effective.

About that very same time the idea of Extreme Programming was evolving. I read a book and thought, well this is much more practical. I started a business and wrote my own form of task tracking system much like what Version One is today. My former co-workers who are groaning at the thought of Version One should consider whether they would rather use Microsoft Project...not me, but to each his or her own. Version One has a list of tasks and you can mark the status of each task, track dependencies, time and more. In my case I had contractors working on billable assignments so I added in a time tracker. They could hit a button to start and stop work on a task so I could create very detailed invoices for customers. I could also arrange the tasks in priority order and break them down into small enough pieces so I could see precise progress. In the event priorities changed I could move a task at the bottom of the list up to the top at any given moment and adjust the deliverables and schedule.

How does this relate to security? In large organizations, many security teams are writing lengthy documents that I equate to the old software requirements specifications. And just like those specifications, I can tell you from the trenches of the development teams in these large organizations...you're lucky if people even know they exist. Sorry. It's true. Even if they do the most well-intentioned employee will have a hard time remembering and following all your rules.

What to do? I would suggest that security people learn from the software development processes how to move faster. Instead of writing documents, create agile backlogs. Create the "Epics" or large work items that need to be completed to maintain security in your organization. Prioritize and fund the Epics. Create stories for the Epics. This may be before or after funding, but either way the stories will evolve over the life of any project. Prioritize the stories. Assign the stories to teams. The teams work the stories in 2, 3 or 4 week sprints. Make sure you work the must-have stories at the beginning so you don't have a half-baked project at the end when the money runs out and you deliver nothing.

Before you hire some expensive consultant to make this all more complicated than it needs to be (which I have experienced), see if you can work with these definitions as a starting point. If you are talking about how to implement the process instead of doing work, the process is failing. Keep it simple and focus on whatever helps get work done most quickly and accurately - and exclude extraneous things that get in the way of getting work done.

1. Team: A team of people with certain expertise or assigned to a project or product.

2. Backlog: Typically associated with a team. A backlog contains the work items assigned to a team. The work items should be in priority order from most to least important. Most large companies have multiple backlogs and teams.

3. Backlog Owner: The person who creates the stories in the backlog. When a story is completed the backlog owner gets a demo of the deliverable and "accepts" the work or sends it back for additional fixes before it is accepted. The team closes the stories after the backlog owner accepts the deliverables. The backlog owner is generally a product manager in the case of a product or a technical owner in the case of architectural or security requirements.

4. Epic: Typically, an epic is a project or subset of work that requires approval and budget. Business executives fund "Epics" just as you would for any other project or initiative.

5. Stories: Deliverables associated with an Epic. The story should define WHAT in business terms not HOW in technical terms. Each story should be short and describe how the deliverable will be tested and demonstrated to the backlog owner to prove that the work was completed as required.

6. Sprint: A 2, 3 or 4-week period. A team commits to complete however many stories it can each sprint from the top of the backlog. If a story takes longer than one sprint to complete, break it into multiple smaller stories.

7. Sprint Planning: At the beginning of each sprint the team holds a planning meeting and commits to as many stories from the top of the backlog as will be possible to complete. In my case I had my each team member prepare their individual commitments in advance so these meetings were typically short.

8. Demo or Sprint Review: At the end of the sprint the team demonstrates the deliverables of each story to the backlog owner and stories are closed. 

I'm not going to get into planning poker, capacity planning, retrospectives, cards and Fibonacci numbers right now. If you just start with the above that will get you going. Keep it simple and focus on getting work done versus lengthy process discussions and meeting overload. Once you master the above you can get fancy. I do believe in certain methods for poker planning and capacity planning that help keep projects on track but the main points for now:

• Put the requirements into a backlog instead of a document.

• Define requirements in business terms (what, not how).

• Break down the work into small pieces.

• Demonstrate work as it is completed and prove it works.

• Prioritize and adjust as needed.

My definition of Agile Security. In a nut shell.

But wait. We're not done. If you put all sorts of things in a backlog that define your requirements and deliverables, how will you enforce your policies?

Write software. You may have an overarching document that defines security policies. Preferably it is on an internal web site - or better yet in a database - and adjusted quickly as policy requirements change. Then, turn as many of those requirements as possible into software that at least monitors for infractions in an automated way, but preferably enforces adherence to policies up front. I have some ideas about this in a white paper on event driven security automation.

What, you don't want to write software? Hire a software programmer. This is the convergence of software and security. I predict that security people who embrace this wonderful relationship with those pesky software developers who are causing all your security headaches will be most successful in the future. And those pesky software developers probably need to learn a thing or two about security!

Epilogue:

Before I tell you that Agile or Scrum or whatever your favorite word is for what is basically a Work Breakdown Structure is the silver bullet that will solve all your problems and all your security initiatives will be completed on time and under budget, I will tell you that Agile has a flaw when not properly managed. You need to have a beginning and an end of a project and make sure things are prioritized correctly to actually achieve a deliverable. Time and money are not endless. Some agile teams assume they are and operate as such. 

Make sure you have a way to determine whether your epic and stories can be completed within your time and budget and manage to that time and budget. This means your backlog truly needs be prioritized so the must-haves are the top and the things at the end of the list can be cut if not completed when time and money runs out on the project. There is also an art to managing people's time and keeping distractions away from the team - one of which can turn out to be your "scrum master" if they are more focused on process than deliverables. Additionally, it's a good idea to understand points, burn downs, capacity planning and how to use those in your estimation process to keep the project on track. 

But generally, I think agile, scrum and extreme programming concepts are better than alternatives for many projects.

Making A Difference

Maybe this blog post will motivate someone who's feeling a bit frustrated when they land here...and inspire that person to keep going when they feel like giving up.

Some days a person can feel like, "What's the point?" You might have some goals that start to feel unattainable, or maybe you are rethinking your goals altogether. "Why am I doing this anyway?"

At these moments you feel like dropping out. Quitting. What's the difference. What does it matter? The frustration starts to boil over and maybe, you think, it would be better to quit and become a barista or a bar tender on a remote island and enjoy the beach instead. Life could be so much simpler.

I was having one of these moments at a certain large company - the company doesn't matter because these things happen everywhere. It felt like I was being blocked from moving to a new department. At the same time I am being blocked, I get an email thanking me and telling me how much the company appreciates five years of my life via some automated email generation system that lets me pick out a gift. It feels very artificial but I'm sure the intention was genuine by whomever designed that system.

I start thinking why do I work so hard and why do I do all these things? Everything is a struggle. Maybe I should just quit running the Seattle AWS Meet Up because it's all so much work and I'm not sure why I'm doing it anymore. I just like the technology and the people but maybe I just need a break...and suddenly - AWS contacts me and says they want to make me an AWS Hero.

What? What's that...I didn't even respond to the emails at first. I thought it was someone trying to sell me something and playing to my ego. I'm no hero. This can't be real. But AWS got through to me and then I looked it up and thought, wow, that is really nice! Someone does appreciate all the hard work. Check out all the AWS Heroes and if you know any of them, it's nice if you let them know you appreciate their work. Maybe even offer to help!

As for that job, I asked some people to give me reviews in our HR system to show how my actions were helping people within the company. I worked with people across all lines of business on a daily basis. I also wrote a blog post explaining how I had helped fix a problematic process at the company. Coincidentally, the company approved the transfer to the new department the same day. I was very excited about the move and working in that department seemed pretty cool. I was optimistic about fixing some things that we all felt were broken.

Then another thing happened shortly after that...WatchGuard Technologies contacted me to offer a pretty cool job. Again, I expose that I am a complete and total nerd and one of my favorite things is looking at network traffic and related logs. I wanted to work on threat intelligence, network logs and security automation. I'm into data and correlation and baselines and anomalies. I think about predictive analysis and real time and scalability and data sharing to help stop the bad guys faster. I think the cloud can facilitate doing these things. I was writing a paper related to that very topic when I was contacted. WatchGuard works with network logs and firewalls so this was a great fit.

Initially I worked on helping the company move to AWS. Now I'm writing for WatchGuard's security blog: Secplicity and doing security research. This so far is a pretty cool gig and I'm excited to be doing it. I once listened to a presentation by the former commander of the Blue Angels. He said something I really liked - when you come to work you should be thinking "Excited to be here". And I am. But sometimes when looking at all the security threats and breaches you think wow, can I ever make a difference? Do people even get security? Do they care?

I was looking for some links related to my Target Breach white paper for a blog post and that's when I noticed something. People are referencing my paper in their research. You can see some links at the bottom of the page. Wow! That's super cool because when I wrote the paper I wanted to understand myself exactly what caused this breach and explain it to other people in the simplest way possible. I wanted to take security breaches out of this esoteric realm and break it down so more people would understand exactly how it happened, and as a result how to protect their systems and networks. I stepped through the breach and each point along the way that facilitated the attack.

And it seems that perhaps, in some small way, this has helped some people gain a better understanding of security and references to the paper are helping to spread the knowledge further to others. It seems like the effort might be helping students learn more about how these attacks are happening. Maybe it will help some of them to go on and better secure their networks and reduce the attack vectors in their employers' environments. Maybe it will help vendors and companies improve security as well.

And as for me, it made me feel like, in some small way, I was making a difference.

And that made my day. And it keeps me going.

-----

References to Target Breach White Paper:

http://www.zdnet.com/article/anatomy-of-the-target-data-breach-missed-opportunities-and-lessons-learned/

https://bol.bna.com/wake-up-call-ashley-madison-lawyers-up-after-breach/

https://issuu.com/pbcwu/docs/identity_theft_prevention_and_mitig

https://www.termpaperwarehouse.com/essay-on/Books-of-Ark/420534

https://www.nist.gov/sites/default/files/documents/2016/09/16/rapid7_rfi_response.pdf

https://engineering.jhu.edu/jhuisi/wp-content/uploads/sites/63/2017/02/Identity-Enabled-Transactions-Based-on-the-EMVCo-Payment-Tokenization-Specification-Capstone-Project.pdf

https://freedompenguin.com/articles/opinion/how-big-is-your-target/

https://www.law360.com/ip/articles/746452/tips-for-guarding-ip-against-cyberespionage

http://repository.law.umich.edu/cgi/viewcontent.cgi?article=1164&context=mjlr

http://www.bucks.edu/media/bcccmedialibrary/con-ed/itacademy/The%20Target%20Breach.pdf

Super Bowl Teams in Technology

I coached a team of 12 year old girls learning to play basketball. When we all showed up I was learning to coach and most of them had never played before. I was fortunate enough to be in a league where there I got a lot of training for coaches. The girls learned basic skills. I'll admit it took me a bit to figure out how to reign in the chaos and what worked.

When we got to the games we had one little all star. But these girls were 12. The point was to let everyone learn to play and have fun, not to win the league championship. Everyone got equal playing time. Even Michael Jordan didn't make it when he first tried out for basketball. Everyone starts somewhere.

From there I went on to coach Sonics kids camps. We coached everyone from students that got good grades to Special Olympics kids. Everyone got to play equally because these camps were for learning and training and having fun. 

When you progress in sports to different levels, the stakes are higher. The point of the game changes. Eventually as you move up the ladder through high school, college and onto professional, the way teams are selected changes. The outcome of the game has a lot of money or prestige associated with it. 

Not everyone gets to do what they want, gets paid the same, or gets equal playing time.

Why?

Because at this level the point of the game is to win.

Now in order to win you have to not only have a team of rock stars, you have to have rock star coaches and players that all have the same objectives. If someone on the team doesn't align with the objectives then likely that team will suffer. Some players might have personal agendas or be trying to be the top dog which hurts other members of the team. Some players may not have the skills to compete at a certain level and bring down your team as a whole. 

So what happens at that level? People with skills get paid. A lot. And players are strategically traded to try to find a team with the right balance of skills. And coaches coach - to win.

Caveat: just because you don't have the top rock stars doesn't mean you can't win in all circumstances. If you have a good coach and players who listen, you can upset the apple cart. I watched my dad coach a team of farm girls that beat all the city kids in a grade school basketball league championship. He took his clip board and studied all the other teams. Then he came up with a winning strategy and led his team to victory. I would venture a guess the other teams had more athletic looking kids with more raw talent. That's what a good strategy can do for you.

That's what start ups do to big companies.

Winning in IT in today's environment encompasses a great deal of understanding of the technical and business landscape in whatever market you are in. That would be offense.

But a winning team also requires good defense. That would be security. If you don't protect your assets all your hard work on offense is lost. If you are giving too much free reign without understanding the threats and liabilities that exist then there's a good chance there's a wide open path to your end zone.

The people working on critical infrastructure that supports all your teams need to understand both offense and defense - and have the skills to implement or the ability to play with the players that have complementary skills to their own. The people on offense need to listen to the people on defense. And the people on defense need to do their jobs without blocking the offense. Otherwise you won't score.

If you want to win the Super Bowl it's not just about letting everyone play. You need a good team with top skills - sharing the same objectives. And a solid strategy. Choose the right players and coaches. Understand their strengths and weaknesses. Understand the game. Understand the competition. Adjust as needed.

But then it all depends what your objective is - do you want to win the Super Bowl? Or are you just playing for fun?

Getting People to Care About Security

I was going to write a blog post on the topic of getting people to care about security.

My notes included covering:

• Quantifying risk

• Quantifying cost 

• Quantifying potential loss

A case study I wrote about the Target breach has some of that at the beginning, including cost to business itself, business leaders, board, customers, business partners and banks.

http://www.sans.org/reading-room/whitepapers/casestudies/case-study-critical-controls-prevented-target-breach-35412

Given recent events, I think the world is starting to care. Sony was hacked by a foreign government. Movies were canceled. Kids' Christmas's were spoiled. Just think if this were an actual war and more than movies and games were at stake....

I think the Sony breach exemplifies the need to take security seriously and the precipice on which we are teetering because security is such an esoteric topic with many subtleties that people misunderstand - or can be fooled into underestimating the consequences. Not to mention the fact that many organizations are breached for periods averaging 11 months before they realize it according to a recent data breach report.

Just went to see The Imitation Game. It's a great movie based on a true story - and one those who tend to blow off the "crazy people" talking gibberish they don't understand might want to see to consider what they might not know and why they should listen.

Fix the Process, Not The People

Some interesting articles about how fixing the process, rather than the people, solves performance problems

Set my people free!

Fix the process, not the people:

http://www.processexcellencenetwork.com/lean-six-sigma-business-transformation/articles/fix-the-process-not-the-people/

Fix the machine, not the person:

http://lifehacker.com/5946530/fix-the-machine-not-the-person

Four Steps to Fix a Process

http://www.aafp.org/fpm/2008/0600/p29.html

Fix a broken system before disaster strikes

http://www.forbes.com/sites/groupthink/2014/07/03/how-to-fix-a-broken-system-before-disaster-strikes/

Stop trying to fix people

http://m.psychologytoday.com/blog/wander-woman/201103/stop-fixing-people

Do Something Wrong and Fix It

I am reviewing discrete math videos. Because yes I am that nerdy.

http://websitenotebook.blogspot.com/2014/03/videos-on-discrete-mathmematics-and.html

The instructor made an interesting comment at one point.

Do something wrong and then fix it. 

This got me thinking about work and life. I get frustrated at times with limited thinking. Oh we can't do this. No we can't do that. People, let's do something. Let's at least try something new and see what happens.

Making mistakes helps us learn. But only if we learn from our mistakes. By taking a chance and trying something we at least learn what doesn't work which is better than learning nothing at all. Thomas Edison didn't come up with the light bulb on his first attempt. He tried many materials to find out which ones didn't work before he found out which one did.

Studies show how mistakes help us learn:

http://m.hopkinsmedicine.org/news/media/releases/memories_of_errors_foster_faster_learning

And how correct analysis of mistakes help us learn faster:

http://www.wired.com/2011/10/why-do-some-people-learn-faster-2/

I have learned for myself over time, that sometimes rereading the first page of a complex topic I'm not getting over and over doesn't help. It helps to go quickly through the whole book, scanning the information to get the big picture. Then I review the material again for the fine grained details. I don't get hung up on every minute piece of information along the way. I want to get to what matters. I don't sit there stuck on page one I just keep going.

This reminds me of people who stall meetings arguing about semantics and the meaning of words and trivial details. They distract from the bigger problem you are trying to solve. In fact I am surprised how many meetings I attend with general discussion topics and circular conversation that have no real purpose or agenda. A meeting should have a problem to solve, a plan to get there, and a deliverable. There is a problem which has to be clearly stated at the start of the meeting - and it has to be the right problem. Instead of talking about all the problems and being afraid of making mistakes or wasting time on distracting tangents, stay focused on the real problem. Make a plan of actions to take to solve the problem. Then do it.

If the actions turn out to be wrong, so what. Cross them off the list and consider the accomplishment as having discovered and eliminated particular actions that did not solve the problem. Think about why they did not solve the problem and then try something else.

Thinking is key to this whole process. I don't want to sound like you should just flail around doing things for the sake of doing them. But taking some action is better than nothing. While working on something and after it fails, think about why and fix it.

I remember performance testing a complex new system and when it took over a day to run, a guy on my team turned to me (somewhat triumphantly as if he wanted to prove it wouldn't work) and said "Well now we are screwed." And I said, "No, now we fix it." Turns out they were running the app and database it two different data centers. Duh. Latency going over that network caused the problem. There was nothing wrong with the application.

This next article talks about the trade off of speed and accuracy. It seems that taking our time solving problems can help us improve the accuracy of our results. However the end of the article considers the cost of not taking fast action in the case of turning off a nuclear reactor:

http://news.vanderbilt.edu/2012/11/haste-makes-waste/

This brings me to my last point. You have to think about what is really going to work. This can be based on research as opposed to pulling something out of thin air with no real basis for the decision. However there is a cost associated with thinking too long. In the case of a business loss of innovation might mean loss of market share -- and creative staff that can drive game changing products to market. The cost of rushing and bypassing security might lead to a Target or Home Depot scenario. But the cost of not taking any risks may put you out of business as the competition passes you by if you are paralyzed with fear of all the potential consequences.

It's a trade off. It brings me back to discrete math and algorithms. You don't want to sit around staring at a problem, thinking, talking and doing nothing. 

Unleash the potential of people to solve problems. Let them try things. If you can think ahead about how to do things faster using a reasonable algorithm that should give you accurate results, use it. If you want things to be faster but not sure what to do, try something that poses minimal risk. It the risk of doing or not doing something puts you out of business, consider of the potential loss is worth it and slow down a bit and think it through. But don't just do nothing.

If you are blocked, stuck or not sure what to do, do something wrong that moves you towards a final solution, and then fix it.

Apple Pay and Transaction Rates

I'm reading some conflicting information on Apple Pay and the related transaction rates. There seem to be some contradictory articles about credit card transaction fees and some hype about Apple's cut.

To better understand the fees associated with Apple Pay it might be helpful to first understand who pays what in typical credit card transaction scenario. This is glossing over some details but here is the gist of it:

A merchant that wants to accept credit cards has to get a merchant account. This is a separate bank account just for credit card processing. The merchant account is linked to the  platforms that process credit cards, that ultimately get the money for the transaction from the POS machine, phone system, e-commerce web site, iPhone, etc. into the merchant account of the merchant. Then the money gets transferred, once settled, from the merchant account to the specified checking account.

Whenever a merchant accepts a credit card, they have to pay a fee. You are all happy that you don't have to carry cash around and get to use your credit card. Every time you swipe the merchant is paying a fee, unlike when you hand over your Benjamins.

The credit card companies and banks have set up this whole convoluted pricing structure for how much it costs a merchant when you pay using a card. For example a "card not present" transaction on the Internet costs more than a "card present" transaction where you swipe your card at a point of sale machine. Like in the store at Target or Home Depot. Because "card present" transactions are more secure and less risky.

Right.

Also processing a card on a web site or alternate transaction processing system might require a "gateway fee" for linking the alternate processing device to traditional processing platforms. Some well known gateways are Cybersource, Authorize.net, and Verisign. PayPal lumps all those fees together. Some merchant accounts do as well - they might raise the discount rate (the fee on each transaction) and eliminate the gateway fee.

Oh and you know that card you love that let's you get cool rewards? That's great that your credit card company does that for you. So nice of them. But actually depending on the type of card being used the merchant may pay a higher rate for those too. Different card brands, vacation cards and debit cards can all have different fees associated with them. So actually you should be thanking your local coffee shop along with the credit card company for you last vacation funded by credit card rewards - or wherever you spent the most money. The coffee shop paid a higher fee for your transactions most likely.

So along comes Apple Pay and the idea is to find ways to make transactions more secure and convenient for consumers. So you get your new iPhone 6 and you are like "Sweet now I can just use my fingerprint instead of pulling out my card and it's all way more secure."

But behind the scenes the credit card companies might be making your favorite coffee shop pay more to have that added convenience. (And that is why the coffee shop offers a discount for cash or have minimum amount for credit card transactions, which might not exactly be in line with their merchant agreement but nevermind that.)

So it was kind of a big deal for Apple to negotiate a low fee for merchants to pay in all this transaction business, besides implementing all the cool new technology. They had to do the same thing when they negotiated a low price with the record labels for single songs instead of a whole higher priced album on iTunes. The price has to be one that people will pay, and although you don't see that price the merchants see it when you swipe and it eats into their profits, and ultimately things cost you more. And who wins? The people getting the fees for processing the cards obviously.

There is a cost and a risk to processing cards but Apple has said it will assume some of the risk to lower these transaction fees. If the fees to merchants are too high they won't accept Apple Pay. It sounds like they have negotiated lower "card present" rates but found conflicting reports. Merchants will want to verify with their banks what they pay for and Apple Pay transaction.

Some other articles are stewing about all the money Apple will be making on these transactions. All they are doing is taking a cut of the fees merchants will pay anyway for helping to facilitate the transaction - and if all goes according to plan - make it more secure and convenient.

Additionally, everyone wants a cut of transaction revenue. The credit card processors and banks control the game. If an alternate payment source comes along that creates competition and lowers transaction fees, that's a good thing for merchants. It should in theory make all our stuff cost less and easier for small companies to accept credit cards (or tokens) for payment. 

I don't know all the details of the Apple deal or who is paying what fees or how much each player is making. I just read some articles that didn't really explain the fee structure or were making a big deal about the fees Apple was getting, so thought would shed some light on how the fee structure typically works.