DevSecCon Singapore 2018 - Insecurity in information technology by Tanya Janca
•Télécharger en tant que PPTX, PDF•
0 j'aime•185 vues
DevSecCon Singapore 2018 - Insecurity in information technology by Tanya Janca
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à DevSecCon Singapore 2018 - Insecurity in information technology by Tanya Janca
Similaire à DevSecCon Singapore 2018 - Insecurity in information technology by Tanya Janca (20)
Plus de DevSecCon
Plus de DevSecCon (20)
Dernier
Dernier (20)
DevSecCon Singapore 2018 - Insecurity in information technology by Tanya Janca
- 1. Insecurity in Information Technology Tanya Janca TaJanca@Microsoft.com Tanya.Janca@owasp.org OWASP Ottawa Chapter Leader OWASP DevSlop Project Leader @SheHacksPurple
- 5. All of this creates the feeling of insecurity about people’s jobs and how to do them well. This leads to predictably negative behaviour.
- 10. Reduction of Organizational Citizenship Behavior (positive workplace activity and involvement)
- 11. All of this negative behavior leads to insecure software.
- 13. The Plan: 1. Support dev and sec team with processes, training, and resources so they can confidently get the job done. 2. Initiate and then maintain culture change.
- 14. The Plan: 1. Support dev and sec team with processes, training, and resources so they can confidently get the job done. 2. Initiate and then maintain culture change.
- 15. The Plan: 1. Support dev and sec team with processes, training, and resources so they can confidently get the job done. 2. Initiate and then maintain culture change.
- 16. The Plan: 1. Support dev and sec team with processes, training, and resources so they can confidently get the job done. 2. Initiate and then maintain culture change.
- 17. The Plan: 1. Support dev and sec team with processes, training, and resources so they can confidently get the job done. 2. Initiate and then maintain culture change.
- 19. @SheHacksPurple
- 21. Start Security Earlier! Requirements Design Code Testing Release Push Left! @SheHacksPurple
- 22. Break security testing into smaller pieces
- 25. 1
- 26. 1
- 27. 1Provide free training to developers1-2
- 28. 2
- 29. (Off Colour) Job Shadowing
- 31. @SheHacksPurple
- 32. 1
- 33. 1
- 34. 2 Give Developers Security Tools! (They just might use them)
- 36. OWASP: Your new BFF!!! The Open Web Application Security Project
- 38. 2
- 39. 2
- 40. 2
- 41. A message for conferences No more “we’re screwed” keynotes.
- 42. 2
- 43. In Summary: 1. Support dev and sec team with processes, training, and resources so they can confidently get the job done. 2. Initiate and then maintain culture change.
- 44. In Summary: 1. Support dev and sec team with processes, training, and resources so they can confidently get the job done. 2. Initiate and then maintain culture change.
- 45. In Summary: 1. Support dev and sec team with processes, training, and resources so they can confidently get the job done. 2. Initiate and then maintain culture change.
- 46. In Summary: 1. Support dev and sec team with processes, training, and resources so they can confidently get the job done. 2. Initiate and then maintain culture change.
- 47. In Summary: 1. Support dev and sec team with processes, training, and resources so they can confidently get the job done. 2. Initiate and then maintain culture change.
- 48. It has to start somewhere…. Why not with you?
- 49. ANY QUESTIONS?OWASP Ottawa Chapter Leader OWASP DevSlop Project Leader @SheHacksPurple Tanya Janca TaJanca@Microsoft.com Tanya.Janca@owasp.org
Notes de l'éditeur
- Who has seen this? Who has been treated this way? The first time I had someone run a vulnerability scan on an application I wrote this is what happened. I received the auto-generated report from the scanner and had no idea what it meant. When I asked the security person for help he told me that I was a programmer and I should know. When I had trouble fixing them he told me that if I was a good programmer I never would have had any issues in the first place. The entire interaction made me feel terrible. It also taught me not to ask for help from security when I had a security issue. This has GOT to change.
- What do Developers do that can make Security feel insecure? Don’t ask the security team’s advice, then write their own crypto. (this is BAD, crypto is HARD) When developers receive the security report sometimes they don’t fix anything, claiming they have more important things to do. Making the security team feel a bit like chop liver. Don’t cooperate to enable security testing, claiming they have no time/implying security is low priority. Do not take or ask for advice from the security team at all.
- What does security do that can make developers feel insecure? Security sends developers a 500 page, auto-generated, unvalidated report. Does not give usable security guidance to the developers when asked. Acts or is seen as a gate, slowing down the SDLC. Adds project requirements without explanation, “because security”. When revealing issues, sometimes they can make developers feel incompetent.
- ** There are many published studies to support these findings that job insecurities lead to these behaviors.
- Deviating from all those nice processes that you implemented in your work place
- Do you want someone with flexible morals handling your precious data?
- An uninspired IT staff is not one that gets things done on time, nor ensures quality
- In a room full of IT Security people I think we all know what this one means….
- Spilling coffee example. When people are acting like this, what kind of software are they making? Are they being diligent? Are they going the extra mile? I think not.
- When people are acting like this, what kind of software are they making? Are they being diligent? Are they going the extra mile? I think not. Review previous points for audience. So now we know what the problem is. Let’s talk about solutions.
- Make sure audience switches gears with you that this is the second part of the talk.
- We are going to go through this the whole way through, for the rest of the talk. This is the entire thing. Let’s work out way through.
- We are going to go through this the whole way through, for the rest of the talk. This is the entire thing. Let’s work out way through.
- We are going to go through this the whole way through, for the rest of the talk. This is the entire thing. Let’s work out way through.
- We are going to go through this the whole way through, for the rest of the talk. This is the entire thing. Let’s work out way through.
- We are going to go through this the whole way through, for the rest of the talk. This is the entire thing. Let’s work out way through.
- Let’s create processes that work. It can’t take 3 weeks to get approval to do 30 minutes of work. There can’t be 21 different steps to get something approved. Someone 4 levels up from me should not be approving a change that I do when they have no idea who I am, what I do, or how it even works. How can they approve that? Let’s talk about processes that work and make people feel confident their doing their jobs right.
- You don’t have an Application Security team? The AppSec Team is the part of the security team that knows software and talks to developers. Helps them prioritize and achieve their security tasks and goals, and teach them about appsec. If you don’t have one, get one. Run, don’t walk. If you work in an enterprise sized business it is not acceptable to not have one, you NEED ONE. AppSec is the cause of approximately a quarter of security incidents, why aren’t you spending a quarter of your security budget on it? I bet you’re not.
- For every new major software project assign an AppSec representative. You Matrix them into the team, this is also called the “Partnership model”. That person will stay on the project and go to major meetings to offer security advice. Anything security-related that the project team needs throughout their project this person will help with, or find the right person who can help. One point of contact with security for the entire project, keeping them on track to make secure software. Caution: do not assign this person to 20+ projects, then they are a bottle neck and therefore also a problem. 3 projects max on top of their other responsibilities!
- Setup a secure SDLC, and start security from the start. Formalize security activities as part of your SDLC. For instance, during design we do threat modelling. It doesn’t matter what paradigm you use, everyone needs to know what they are building, make a plan, code it, test it and then perform maintenance. So formalize it.
- Security testing is cut into smaller pieces, so that it is more manageable and preferably does not slow down the SDLC any more than absolutely necessary. For instance, doing static code analysis that only looks for XSS in one round, then another that only looks for SQLi, rather than doing one huge sweep that would take 2-3 weeks to analyze. Security needs to learn to sprint.
- Ensure that all the results from automated tools have been fully validated, no more false positives. If you are unsure, hire out/get more training. The reason for this is that you will lose the trust of the developers if you send them on wild goose chases. Also: if the output from your automated tool isn’t good enough for YOU to read, why do you think it’s good enough for developers to read?
- When I say training here I don’t mean “general IT Security Awareness”, I mean training that is specific to the work that you do. How to do the responsibilities of your job more securely. If you code, security coding training. If you design apps, I mean threat modelling and secure design training. Etc.
- Do you see this guy? Do you know what he’s so stressed out? It’s because he thinks he needs to know everything. No one needs to know everything. There is no shame in going on training so that you have a better handle on what you are expected to do for 40 hours+ per week. If you are weak in a specific area, ask for training. If there’s no budget train yourself online. If you still don’t know, call a pro, that’s why the build us consultants in the factor. Never leave important things as unknown or ambiguous, this is where insecurity starts.
- What if we actually taught all of IT what security expected from them? If developers have a budget for only one course per year (or less!), they are NOT going to spend it on a security course. They are going to spend it on the cool new JavaScript front end framework or whatever else it is that is currently bright and shiny. Provide security training and you will see your security posture improve.
- Provide free security training to developers, and the rest of IT while you’re at it. They should not be expected to pay for this out of their own training budgets. If you are a developer and you “need to know everything” for your job, you are not going to spend your limited training dollars on security when there are ten other topics that need your attention this year. But if the training was free and you had approval from your manager to attend…. you’d be there in a second. Make this a reality for the dev team and watch your apps become more secure overnight.
- One more thing: Don’t do it once. Keep giving the training. I don’t want to hear about “that one time we gave them training, in 2012”. Keep doing it. This will help create a culture that “security is everybody’s job”, which is exactly what we want. Right?
- Another interesting way of learn is job shadowing. I’m not thinking of the usual sort of job shadowing, I’m thinking more of a “death by fire” type of job shadowing. Bring a developer on a security incident, the whole way through. Let them see the damage, the stress, the cost. The next time someone from the vulnerability assessment team gives a report with a false positive in it, make then go fix bugs with developers. So they will see the countless hours wasted when a false positive is sent. You know that saying “Walk a mile in someone else’s shoes?” Yeah. That.
- Let’s talk about resources. Because if you don’t have what you need to get the job done, the rest of this doesn’t really matter, does it?
- What if, instead of making all of IT read our minds, we explicitly defined what we wanted from them? What if we wrote a short, concise, understandable document with secure coding and secure design principles as a set of rules for developers to follow? For instance, ”all external facing applications will be accessible using HTTPS only”. Their app should be in pretty good shape from a security standpoint if they follow all the rules. I do NOT mean a 200 page check list. I don’t mean, a link to NIST or some other security policy. To be clear: I DO NOT MEAN compliance. And for the record, whatever you come up with must be easy to find, well socialized, and above all it must contain only security advice that is USABLE.
- The security team is NEVER allowed to respond to requests for help by sending links to extremely long documents (ITSG-33 or NIST, for example) that are essentially unreadable to non-security-people and leave them more confused than before. Give specific and detailed advice. If you don’t know the answer conduct research or hire someone to do it for you. Not answering is NOT an option.
- A company MAY NOT publish an unreadable (too technical/all security jargon) to an unfindable/borderline-hidden location onto the intranet and call it a day. This is NOT useful. This is not helpful. This is making a problem, not solving one.
- Give developers security tools; they might actually use them. Give them web app scanners, give them static analysis tools, buy them books, whatever they want. Help them use them, show them how. They are basically doing your jobs for you! This is a great deal!
- Try not to worry about who has to pick up the bill. Try. Try. I realize training and consultants costs money, but 1) it’s worth it if you need it 2) consider it a long term investment, 3) you are getting your mandate done by releasing secure applications and 4) it all costs less than a breach. All of it.
- Invite your developers to participate in OWASP. Offer to host it at your company! If there isn’t a chapter in your city, start one! This is a great way to get your developers interested in AppSec, because they are the care bears of security! Make full use of this excellent free resource!
- Now it’s time for culture change. At this point we’ve supported everyone in doing their jobs, and things are way better. But culture will cement the deal.
- From now on when there’s a problem, don’t blame someone. It’s not Bob or Alice’s error that is the problem, it’s that there weren’t processes or safeguards in place to stop the problem from happening. We don’t care about the who, we only care about how we are going to fix it, and then ensure it will never happen again. This is called a Blameless Post Mortem. It’s okay to fail. But it’s not okay to not learn from it when we do.
- If at all possible, always allow someone to “save face”. It will pave the path to a more friendly future.
- Physically locate the application security team near the developers. It’s more difficult to be rude to someone’s face.
- If at all possible, stop booking the “we’re all fucked” keynote talks at security conferences. The ones that present huge problems but few or unclear solutions. They do not inspire confidence, so why give them audience? They do not help the situation, they only discourage security practitioners who already have an uphill battle.
- If you are a leader in your workplace, you will lead your team the right way, or the wrong way. Whether you mean to or not. Your team and everyone else is watching you and learning from you what is acceptable. You get to decide what tone you want to set, every day. Set the example of the positive ad professional culture you want, every time you speak. Every time you act. If you speak poorly about another team, you are saying that’s acceptable behavior in your workplace. If you use profanity, if you yell or bully. You are teaching everyone how to act. Provide leadership towards a culture shift, a shift to where people are polite, professional, hardworking and accountable. Lead by positive example, and they will follow you wherever you go.
- Summary
- We are going to go through this the whole way through, for the rest of the talk. This is the entire thing. Let’s work out way through.
- We are going to go through this the whole way through, for the rest of the talk. This is the entire thing. Let’s work out way through.
- We are going to go through this the whole way through, for the rest of the talk. This is the entire thing. Let’s work out way through.
- We are going to go through this the whole way through, for the rest of the talk. This is the entire thing. Let’s work out way through.
- I call upon all of you to be the change you want to see. Be the bigger person. Be the one who admits they were wrong or that you don’t know. Keep a higher bar for yourself and your team relative than the rest of the company in terms of technical skill, professionalism, everything you do. If we are going to win this battle, we have to change the way we are doing things. This is a call to action. It has to start somewhere. Why not with you? PAUSE Thank you for your time and attention today.