A Summary (iRobot)-------------------------tl;drTooLong; Didn’t Readhttp://www.urbandictionary.com/define.php?term=tl%3BdrAKA: Its better to find flexible sort of smart young talent that you can hire cheap, for your get rich quick schemes.Also known as this world changes so fast, and newbies are so cheap, that we can change the world and outcast all the wise thoughtz.Yay?!?! --- FAILzOR… If you have enough money no one knows the difference.OR… What are the chances that you have created a world changing idea any way.Ahhh Security the ivory tower we seek to climb, but never manage…
Intro to Exhibits-------------------I noticed that the best way to communicate security information to associates was through really well completed video talks (Like the OWASP AppSec Tutorial Series). They grab peoples attention if they are good enough, and communicate the issues in a broad way that easily demonstrates risk, and the reason prevention is so important.Michael Howard from Microsoft gave a KeyNote at OWASP AppSecUSA in 2012 stating that security awareness, training, or education won't work if it is too long or overloads the listeners with things they can't possibly retain. So... I think it is best done in short presentations that can explain most of the information rather quickly (ie. Zest/Punch). Of course it never hurts to have a whole wack of information available to back-up your story (you know like a book or two), or even a whole website that can get people started, when looking for more information.In my opinion there is vey good information out there on a plethora of different security issues, but nothing seemed to properly describe the full risk, attack, remediation, fix, and secure lifecycle for a number of security issues. Your company can partner with Security Companies to bring in Security Awareness materials, but when they take a couple of years just to arrive at a decision about who to partner with… what do you do?I can tell people to fix security issues, but if they do not understand the W5 surrounding the issue, or importance, how do I encourage an organization to fix the really deep flaws/bugs that are beyond simple to fix.This is where I think it is important for Security Engineering to model what real attacks are capable of, and demonstrate the real risk/rewards issues.Its not as if the thought on software security just started in 2011. It has been a serious topic at least 20 years before that (with the Morris Worm...) and we have lots of amazing free tools out here to help us communicate to people in interesting and imaginative ways, how an attack might actually occur.This why I dreamt up creating the following video. I didn't want their to be any mystery for my employer about why it is so important to fix Security Bug X.I also wanted to communicate the real client side risks, even if we could only consider ourselves as just one of multiple offenders (in the software provider community).
Init Milieu-----------Some bugs are easier to fix than others. You might one day start a job for which there is not a first time Vuln find, but a whole history of reports damning the same certain feature.If this feature comprises a part of the most active/popular area of the company's external facing presence, it might not be something that is fixed right away.After you have reviewed/performed the millionth assessments you have been asked to document or perform, and you've approached all the dev teams concerning a fix, you might be feeling a bit bored, or damn frustrated.I suggest that with this extra time you don't focus on forcing people to fix things they don't want to bother with, instead I suggest you take the bugs that they like to fix, and blow them out of the water.Detail for them how such a bug might allow for watering hole attacks, planting rootkits, and persistently infecting a computer.
Stack it up-----------Create a damning body of evidence detailing exploitability in the bugs they have a history of fixing, so that when you return to the persistent flaw in the middle of their offering next time, they don't want to mess with ignoring your advice.Use the bugs they are aware of... and then go 10 steps further. Go right to APT if you have to. Show them how little they knew about their favorite bug, and help drum up respect concerning all the other request you have made of them.With certain security bug classes like the class XSS falls into there isn't just one problem area that software developers should be aware of. Remote Code Execution capable bugs, could be broadened in how we define them to Developers. Why not start there?While an XSS might divulge a user's session cookie, and even that is a really really critical issue to fix, certain individuals might rightly state, well a login provided to such and such a feature has no access to any PII/PCI information. So you see what this XSS provides to an attacker doesn't really mean anything, because that webapp has no access to critical information assets.What such a response glosses over, is that exposing a User's session cookie is only just one issue of a plethora of other possible attack vectors possible via. RCE.There are also other aspects of the problem, which we can share with Developers that they might not know about.
Raise The Bar-------------I think taking these easy sorts of bugs and using them to raise awareness, is just the sort of thing that is going to help you communicate to an organization even more.Take the serious bugs you find, and see if you can't also find a treasure trove of them in a library, component, or thirdparty code.Use these found bugs, as an entry point for describing real attacks that could end up compromising their system, and the systems of potential customers.There is nothing like seeing your own code, or your company’s backends in a security vulnerability, the whole company can later see on a security awareness video. I think Internal Disclosure it a great impetus for getting your security program rolling. If you are struggling with getting management support, attempt to work with them to at least put on an annual security awareness session. In the session you have the ability to drop legalized 0-days. Your working for the company right?You should push to have things fixed right away, but if they haven’t fixed it in the three months it took you to polish off a good security awareness video… Something is wrong!Don't allow yourself to make a dry video. Use character acting to express the problem, to get yourself into the subject if you have to. Get yourself excited/sure about the problems, by “taking the training”, and knowing what the problems really are.All of us as software developers are smart, and we automatically want to do a search, read a book, ask some friends, or take a local course. We’ve done it before, we’ll do it again, and we know we can get ourselves trained in some area if we really want to…However the thieves are not going to come to you door and tell you how they did it!I think that is why you have to work with a potential employer to partner with up’ing your own security awareness.Why reinvent the wheel, take a course, and get a professional to tell you how things really are.Security training costs money. I hate it, it sucks, and I well I just hate the idea that many things are not free… Give it a shot though, put some time and money into it. Whatever it takes to shake you up enough to make it work for you. Don’t give up on your security career just because it doesn’t seem to be working for you… its working for the criminals isn’t it? http://krebsonsecurity.com/I didn’t go looking for a job in security. I just wanted to know how to code well enough to create my own company, and also be sure I wasn’t defrauding millions of people. In the end I think that is why I am doing what I’m doing right now, anyone can get a contract but not everyone can help shape the integrity of a profession. Which kind of developer are you?
http://thezork.deviantart.com/art/melted-boi-graffiti-269041433Thezork : Nestor Marinero - Artist | Professional | Digital Art - El SalvadorWhat We Have ------------There are so many awefulyoutube videos out there on vulns that are mind numbing. Vulns silently displayed with no story behind them, and a whole lot of rap music.People have tried to make hacking look so cool that it doesn't appeal a simple person, and so common that each video tells the viewer nothing new.A smart person might not have the time to connect the dots as to why it matters, and an inquisitive mind might also stop just before learning about the riskier issues.I think we need to in a way be like Disney, and explain these things so simply that a manager could comprehend it, and so detailed that a developer could follow along with us as we describe how an hack works.
The Official Security Awareness Business----------------------------------------For two years I heard corporate security staff talk about creating security awareness within the organization.I saw lots of money being spent, but I saw no real action in the arena.Finally I realized the calvary just wasn't going to be coming, and my career was sinking into the mold… with a ship headed in no specific directionWhen I started making explanatory videos, it seemed like things started to click within dev groups.Just after I created this expose, which completely knocks it out of the ball park, that I am not an awesome video creator... Guess what my company decided to finally enroll the company in the Security Awareness material a security consultancy had created.. However will anyone in the company actually take the courses or complete the material?I would love to get the time... is probably the answer we all have concerning this.And perhaps I will be the only one to review it? That is what happened the first time we sampled the wares.
Resist the urge to out-source it all and keep it (organic to the business)------------------------------------If you create a company directed security promotional like this, which you can post links to it everywhere: Wiki Bug Pages e-mails chat etc.There are quite few more chances for people to run across such material in their day, or when they are given such a bug to fix...By peaking people's interest we are exposing the worst issues and trying to build integrity in what we say to the company so that the company can build integrity into what it is saying to the world through its software.
Mix your research with company facts------------------------------------I spent time effort and money to trace down how to exploit XSS beyond the session cookie facts, because it seemed highly interesting.As researched more about it and spoke with more people about it I gained support from people interested and knowledgeable about the domain.I also managed to find an XSS deep down somewhere in library code that no one would have thought about in several billion years of computer time.It might not have been interesting to them but it was interesting to me. If internal company tools can be used to compromise co-workers etc. what sort of diabolical things are possible.Its not all about being proper when we are describing an attacker, sometimes it is just about what is possible, and letting people know that the ethics we believe in do not necessarily drive the economic horse.Now I know I am playing devil's advocate here, but it is for a good reason. All of these things are possible, so why is it we are not compromised everyday... is it not a necessarily good attack? Or do people working for the same company usually not attack one another?Right we all work for the same employer, and so we have real reason to treat everyone else with respect. Its called business etiquette yes?Where have you seen business etiquette go in the last few years of your career?
Content Creation----------------You don't have any content until you dream up your attacks or successfully exploit them.So focus on your attacks first. Investigate the attack/assessment tools at your disposal.Practice with them. Use them.For many years I've known about security issues that could be exploited, however I decided that I had already been paid off not to make an issue of them.The first vulns I found after just a full year on a job as a QA. I didn't want to work in QA, I wanted to work in development. However my interviews didn't turn out the way I expected. Instead of getting angry I got smart.I devised a way to send all sorts of data at our applications using a bunch of code data structures and random bytes. This is before I had learned this was called fuzzing.In the end I had created repeatable system crashes with specific ascii character codes. At that time I knew this was bad, but I hadn't quite studied exploitation yet. However I deemed doing such a thing would not help the career in any way, so I shelved my thoughts and kept up my search for that great development opportunity in the sky.I was an ostrich in the sand so to speak. If you are employed as a security professional, there is no reason to have your head in the sand. You need to master your tools, just like a martial artist needs to master his moves.Learning the tools with help you to do the right thing, and teach people why we need to avoid making vulnerable software.
Perfecting Your Attacks-----------------------When you have figured out your attack, you will most likely be able to do a google search of some kind to find out how to take your exploit all the way.There might be a good related attack out there on video that really catches your eye.When you find it it will add to your excitement to take it all the way, and explain to other people how a potential compromise could occur.For me the attack that did it was the Aurora attack. When I saw this attack I knew that I had stumbled on the vulnerability I expected was possible, but did not know for sure was viable.Sometimes it take just a little find to make you fall head over heels interested in a subject again.So practice performing your attacks. You will notice that it is actually not as easy as you might expect, but the more you research the attack side the more you will discover that most everything is possible.At some point after practicing you will realize that it actually can take quite a bit of work to set everything up.Further more to make your attack understandable to an onlooker, you must take time and be very explanatory.
Perfecting the Explanation--------------------------If you don't show any exploitation, there is really no need for any explanation. If there is really no risk, then no one is interested. Don't be fooled, we need to tell the whole story and not be afraid to describe real weaknesses, or learn about them ourselves.Have you ever seen anSQLi in real systems? Trust me it is a really scary thing to see live.One we have practiced the attack, we will have a great clue about how we want to relay this information in the video.I suggest recording videos of your exploits, in a way that you believe will be easily visualized by strangers who don't know you (Or even developers you do know).Use multiple VMs and record the various screens. Its okay to leave in your switches between VMs, you can easily cut them out of the videos later. Be liberal with you video footage since every thing is editable, and actually you might want more video given explanations can sometimes take a while.After you have what you want to show people recorded in video, then review the videos and start to create a script to describe to the viewers what is actually happening.You will need to work back from the exploit to create an introduction.
Post Mortem and Introduction---------------------------- After you master the attack, you will realize that the Explanation really isn't that hard either.When you create your explanation, don't forget to tie it back into reality. Feel free here to use a simple attack that replays the story.But show them the proof of the attack, what is going on, and how attack relates to other attacks that the listeners may actually have heard about (ie. click jacking, Facebook login overlays etc.).In some way this is more than about just one vulnerability, its that one vulnerability can be just as good as another, and all vulns relate to attacking.We need to harp on the Attack line especially because we have just shown how possible a technological attack is, and they might never have seen one before.After you create your explanation, you will probably have a good idea about how to create a good introduction.After creating the explanation and introduction, I realized that I really needed to also include a piece about how to fix the broken software used to highlight the attack and specific architectural weaknesses.We'll to be precise I wanted to get to this point before I did the explanation... however I realized that jumping to the fix before really helping engineers actually see the bits going over the wire, might be going to fast.Your explanation should be detailed to the point of reviewing specific network packets that provide proof of compromising actions.
Creating the Story------------------Once you are able to tell a story through your video footage, creating the verbal content should come easy. Not only that but it might relate to real life.The same month I made this video my A/V caught its first ever web attack.So I placed the real A/V warnings into the video.You might have to redo a video here and there, you might find out your dialog just isn't a perfect...You will definitely findout that every video editing software crashes at the most in opportune time and is an F'ing bitch to work with.Ok this is especially true of MS MovieMaker... then Premier... etc. iMovie never crashed on me before, but I've done precious little with it since 2011.I found that as I created the Attack, and Exploitation, more and more content and ideas came into my head.Judge for yourself whether it is going to fit your purpose. I would suggest performing at least three attacks: 1. The one that everyone expects is possible, but do not really know how to pull off. 2. One that goes full circle to exploitation, and leaves people's mouths dropping. 3. One that can be automated and makes people start to question the reality of the web we live in...
Why do people care again?-------------------------Fine you've stolen my cookies, but I can just go and buy some new ones right? Why does it matter?I didn't know how I should tie XSS exploitation into an introduction for viewers, but then I thought about phishing and decided it would be a natural selection.When I started into it, I though it was even better because it didn't make very good sense to even call it phishing.It then seemed comical to me that I would phish myself or even dream of phishing another employee.However when I conceived the idea, it actually made way more sense to me and also made fun of ancient attacks. After all if just clicking a link can take you straight to a client-side zero day, is that a phish or a phrack.That is really the point I wanted to make real for people any way.Ever since that point in time, I have realized that anyone who has ever created a website, could have actually also attempted to exploit my computer, instead of provide me with something of any value...It's a scary thought, a different kind of realization, and an important almost blaphemous point to raise...One of the reasons people are being exploited all the time via web servers... is that most every Web Developer has no intention of doing that...Well... almost every web developer... right?
Detection---------Did I say I wanted to jump in and fix the problem? No... I could create another e-mail alias and post the bug as a different person to the same bug bounty program... why not... its money in the bank right? ...Ok off topic, but developers don't become security conscious, just because they understand all the right programming techniques... right?No a good... secure developer... will also know how to test his own software. SecurityTestDrivenDevelopment (STDD)No one has time to do code analysis on all the libraries they use, so they should probably perform some amount of security testing in their own development environment.So that they also ensure the dependent libraries they are using also do not suffer from security weaknesses.Sadly before you can show someone how to fix a security defect, you should first show them how security bugs can be detected. No bug fixing strategy is complete without first reviewing with Developers how they can perform a rudimentary assessment on their work before shipping.Show them detection... and when you do illustrate how in your face the bug is. In the final attack, include some very public facing graphics of your company.Make it clear your company has a problem, and its a problem everyone can see... tie this back into company reputation.If developeres don't review their own fabrications and designs for security flaws, there might be no way to actually help anyone change for the better.So review causation with them, and the problem of liability. If not directly, then at least make strong hints at it.
Remediation-----------I wanted to dive right into 'fix the software stupid', but it might be equally good to cover remediation depending your own situation... Personally I made the video for developers because I wanted to keep well away from virtual patching.Yay I got to the point of actually fixing the vuln... see here...? Its easy to be a security conscious developer right?Well how many supposed self professed computer coder hacker gurus out there really understand any particular vulnerability.Look at Buffer/Stack/Pointer overflows etc. This is not a just a simple problem with easily implementable protections...Remote Code Execution(RCE) bugs are anything but simple, and prevention against these types of vulnerabilities is even harderWhen you explain how to fix the issue, let them know they are just at the tip of the iceberg.Take them to the best sources you know of the definitions of the problem...Take them to Frameworks that contain preventative methods to provide for protection...Take it all the way home.The video I made has 20 minutes about the detailed prevention of XSS... and really I was only just getting started.This is by no means just a simple hack with simple preventions. The preventions are complex and detailed (ie. CSP)
Make it Social----------------There are enough boards/lists/pages/feeds out there to provide good input.I’ve started a twitter feed to help socialize security issues.Right now it seems many security wonks are on Twitter.In the future… who knows?I’m not using wonk to insult here. In the case of someone with a good balance, it might be good to fall out of the standard deviation.For Instance---------------Manico also gave a great talk at AppSec USA 2013 last year where he talked about using HSMs to store cryptographic keys etc. and there by using a less expensive set of salted-hash functions for cryptographic password/residual checking.When security goes social then we all benefit.
Killing It with Detailed Prevention Guidance--------------------------------------------I had a hoot creating this video, and no I'm not talking about partying all night long drinking beer and getting wasted...I just loved the idea that I could try to blow open the doors on closing the XSS security gap.I also marveled at how deep the OWASP XSS prevention advice went.I wanted to go further, but realized the audience just wasn't going to make it on the journey with me.At some point they were going to bail out... and I had no idea at what point they would stop following the curve ball.Don't go so deep down the hole that no one will go with you... or if you do go down the hole, be prepared to take some flack for it.However in reality no one is going to shame your video if you killed the attack/exploitation side. In fact take it as far as you want... just make sure that it is potent in what it portrays. For heaven sake don't bore any one. If your going to make a horror film of it... just leave out slow/spacey zombie profile shots that do nothing but waste people's time.If you stick to the point developer’s should be able to take you seriously.Make every minute of what you present count... and put all the best of your work at the beginning. After all if they don't finish the video, and don't understand it all no one is going to blame them anyway.This video is all about capturing their attention gaining respect for the industry with your development community...and convincing them its not all black hats and pen testers. It is possible for an ordinary person to understand hacking, and it possible for a developer to be ahead of the eight ball if they are willing to go down that rabbit hole.Remember to create a wiki page that goes way further than your video could (just incase someone out there is listening).Your wiki page can consist of everything they might need to know about prevention:Fixing, Gotchas, Dependent Fix gotchasFrameworks to use, that help make prevention a realityIf there are potential counter measures to use, talk about them, but more importantly document them in detail.
Justification-------------Before you complete this video you are going to ask yourself how in the world a company is paying you, to reveal activities that largely lay shrouded in mystery for most.It might not come to you at first but after you develop your techniques, you are going to question if your wage really pays for you to make a movie.If you don't question it (like you should), then someone else probably will. This is especially why it is important to gain the upper ground, in a corporate philosophical discourse.Personally I was willing to put my own time into helping change something so weird as corporate milieu.If you enjoy what your doing, your doing something right. Don’t stop.Ensure you specifically meet the Business/Programmer Niche that is appropriate for your company.We are not looking to offend people, we are looking to draw them into the security discussion.I believe I was lucky, we have probably a every type of programmer archetype known to man in the company.However speaking developer-ese is truly how you are going to make this thing work.Speaking business-ese is also important. Think about it at least a bit.The person that can bitch slap all the other people with the reality... this does the job, its 8000 times cheaper, and one million times moresecure… wins every time right (Well maybe in my dream world.)?Make your argument about being a billion times cheaper and 8000 times more secure.No matter what type of arguments are made, purposefully plan to win each and every argument.If you don't win the argument at least come out to VanCitySec and tell us all about it.Your security problem is every bodies security problem.However we really need to learn how to lean into the issues, if we are going to make headway.While this issue is very old and perhaps this video is like unto a funeral…new pressing/exciting software security issues are bound to occur.If we look at the history of software security, the issues are getting worse, not better.
Identifying with the Management Layer-------------------------------------So after I had taken this a fair ways... I realized that the PMs who have sold there lives, to end up wrangling the common sheep-mule like issues.At one point were probably tech-wizards, and had their whole potential set of patents they could file,and Jobs-ian alternate realities they could have created...But instead of being a slave driver... they wound up becoming a manager. These people are not dumb, they are not poor, and they have enough contacts to see you lying face down in a puddle of heroine not so far from China town, and way beyond the help of Welfare or the Maple Leaf. Just joking here... But stay focusedOK seriously they sacrificed a good potential career for the bacon... and well the company doesn't work without them.Not only this, but without your management team you would not even be hired...I know your depending on them for things right? Everyone needs a day job? Hmmm… all these things are interesting to consider…And well what I am saying here is that you need to sell the idea of security too, not just whatever else it is you do. If you can’t sell it to yourself, then maybe its time to quit?So everyone counts in your security awareness movie... Even Management!!!You already must ensure your are polite, speaking to the developers, and speaking to the hackers...Although we know it is impossible to do everything...The company is calling your to do that...? and well crunch crunch salty saltysalty... you've been eating the bacon too!!!!!!!!!!!!!!!!!!!Or at least the cost of admission.
The Golden Blueberry--------------------So what you need to do is rethink your introduction. You thought it would be good to dive right into the attack didn't you???However you could wisely.... I REPEAT wisely decide to create an introduction that justifies the business need for such a video right?Lets cover a vulnerability report. Let's describe to a software company, what they really need to know about the state of software security...Your real introduction should also cover the formal identification for the vulnerability discussed.If people see your preso introduction and don't see an attack they can recognize, they might lose track of what your are taking about. Start where they are at, not where you are at, and slowly take them there.At the very least you should include descriptions and discussions about vuln identification, that any moderately experienced person could identify with.In my video I used typical XSS pictures and descriptions to identify the problem... I also highlighted examples of vulnerability detection that everyone is familiar with already.In the case of buffer overflow this might come in the way of seg-fault/core dump or shell prompt etc.I think its the Golden Blueberry, that allows us to take it all the way.Take a look at what we’re doing as an industry.The only way were going to do it well, is to sell it as good or better than they are selling other things.The good thing however is that you can create a road of your own choosing.
Posting the Video-----------------Hash this over with everyone in your contact list, try to find the normal corporate locations to share this video.Don't post it on youtube, if your video is any good you have company relevant information in your video.Keep it secret, but ensure that your baby is in the best place for everyone to see.In other words if you have a fast fileserver.A masterful corporate video website etc. etc.At this point it is all about publicity.If you would dare to use YouTube,I would venture that you have not made it personal enough to the business yet.We can always go a bit further.You might want to put something in it that describes a potentially libelous business risk.With an internal video you can leave it so sharp as to be dangerous.If your going to make it public, trim the claws so that you can seat the issue with a greater audience safely.
Communicating the Awareness Session-----------------------------------If your video hosts information that is new to you, and you are passionate about it,make it a big deal.If you have access to the dev/qa/release/cm/ops/management e-mail listsinvite everyone out to have an open forum discussion about your security awareness video.Send them an introduction e-mail with a link to your easily accessible video,that they can download and watch.Tell them to watch the video, and then come out to discuss the topic with you.Ask the whole group when they believe the best time would be for them to attend an info session on the topic.
Prepping for the info session-----------------------------Book a time and place where everyone can come and openly discuss and review the video content.For instance they may have mis-understood parts of the video... Hopefully not if you were paying attention to making it slick and easy to follow (but anything is possible)Create a slide deck, that just destroys the topic (from an answers point of view).In your video you punch a whole through the roof, on just how sick VulnX really is for the company.In the presentation we get to cover all the rest of jazz.Here we can be very instructive, and even cover academic aspects of the issue.However make sure this presentation, is about reviewing parts of the video with the attendeesThe real reason for the info session is to include everyone in the topic.We review each aspect of the video trying to ensure we have covered all the basis: 1. attack - The whole history of the attack and reason for management concern 2. exploitation - XSS can lead to complete device compromise 3. detection - How could we properly test to ensure these bugs are less probable in our code. 4. prevention - What library features could we use to help ensure these bugs are less prevalent 5. protection - What external controls are available to limiting what our application can do (ie. CSP/EMET/ModSecurity/FW/AV/WAF) 6. monitor - How might we make use of protections to create an OODA Loop for keeping such issues high on the radar (ie. audit monitors)?
Holding the Info Session------------------------Here we will review the video.Our slides are matter of fact, perhaps boring... however the content is anything but boring, complete compromise? COMPLETE COMPROMISE!That is why in this info session it is all about asking the audience questions.You want to engage with your audience, make sure they understand the depth of the problem and asks them to start thinking about it.Have a starting slide that asks of them...So what did XSS allow us to do to our victim? Just steal their session cookie? But didn't we also gain access to their box?Here we want to highlight the knowledge of our employees, not entirely present new things.We want to be able to ask them questions, so that we know, that they know, what it is we are talking about.If no one is asking questions or as excited about it as you, try to start asking them just why that is.Is it something that you don’t know about the group/company?
Results-------Unfortunately from my experience here... I don't think anyone listened to the video, or came to the meeting willing to provide anything new...Or even ask answer/questions.Its important I think to ensure that everyone is on the same page with killer attack capable issues like XSS.If we question XSS properly with groups, it will lead them to also question Mal-vertizements...and how probable it is that Ad networks and watering hole style attacks are happening all the time.Drawing it back to issues that actually affect developers, and are in current news articles is important (ie. watering hole attack).Co-opting the Dev Team----------------------Smart/co-operative developers are really a God send (but rare). The best bug I have had the privilege of communicating in my group came from a developerI tried to be open and honest with everyone in my company.Reaching up to the CISO and management, across to company leads and down and out to contractors, and even unrelated corporate workersBelieve it or not even HR can help you spread the message of securityOne IT worker I met this year told me he got HR to alter company policy, to help prevent obvious oversight in corporate process issues.If your corporate processes don't allow for silly things to begin with, some risks can be shelved.We might not be able to stop attackers, but there is nothing wrong with having your own ship clean-er.
Cornicopia----------If you have come full circle in your video and wiki pages, you will have probably have covered the following: 1. attack 2. exploitation/explanation 3. detection 4. prevention 5. protection 6. monitorin other words you will have MAPPED the issue (Now... you make up an acronym too!): Monitor Attack Prevention Protection Explanation/Exploitation DetectionIn general developers don't know this stuff because we are telling them... and were not relating it to them or the business.Essentially the security industry has a way of detailing the bug types, but not fully explaining/entertaining attacksIt does take time and money however to create a great video.This is one task I think security staff can help doing, to make certain bug tracker issues more personal to the business.Were not speaking the language really?--------------------------------------The starting admission by Gunnar Petersen seems pretty factual at the moment.Money is king, security costs money, but who's protecting the queenand who is telling us the best ways to do so.There are so many other great people out there with great admissions, summaries, and reviewsManico, McGraw, Wysopal, Crockford, Grossman etc. etc. etc.The list is endless.
Help the People to Start Listening to you-----------------------------------------Find creative ways to include them in the discussion, Adam Showstack says: we should see to learn more about why developers don’t want to fix the problem.One way he suggests to do this and avoid probability arguments, is to give an example concerning real accounts where issues like the one levied, have been exploited in the wild. He says the goal of this method is to delve into the issue of why dev team X does not want to fix the issue, and avoid debates about attackprobabilities justifying if it should be fixed. Is it worth dev team discussions? Adam says it is.John Wilander states we need to remember Software Priorities According to Developers are more likely: 1. Functions and features as specified or envisioned 2. Performance 3. Usability 4. Uptime 5. Maintainability 6. SecurityJohn Wilanderhttp://appsandsecurity.blogspot.se/2011/02/security-people-vs-developers.html
Immersion---------So that leads us to the topic of, how do you communicate this to your companyIdeally you have researched: the exploitation topics the corporate vulnerability historyStayed aware for your company about: what was out on full-disclosure, bugtraq etc. or available out there through other sourcesParticipated in: penetration tests on your groups assets leading the bug triaging process assessment/reviews on your groupAll of this information has given you a good understanding about what sorts and types of bugs are high risk items for your group.
Modus Operandi--------------If you have been at this for a while you should be bitter.If you like to program as much as I do, your also upset your moment in the spotlight never came.No one has shone the light on you... so now it is time to shine the light on other people's bad bad world.How will you choose to spread the venom? It might depend on your character, good. However none of that star child stuff really matters here.Here we want to espouse exactly what is wrong, why, how it can be detected, and all the helps and hints that other people need to be aware of.Think of yourself as the eyes and ears of your company/group.No one else was listening, so you had to.No one else cared clients were being co-opted by some government en Afrique, SouthAsia, Eurasia, Sud et Nord America, Oceana and Europabut you did...put it all aside, there are probably at least a handful of smart people at your company that give a rip right?Out of luck? Well then maybe its time to re-enter the contractor life, because this job is going to require management, and/or people who self-lessly care.Your on a mission... think about how you can really make a difference. and Apply your own individual styleIf your committed to this you might try making a whole career out of it (or a personal corporate mission).
Preso Break Down----------------Actually lets start with getting management buy in... Then lets detail the lay person understanding/storyWhy not include a attack flow diagramNow lets think of a basic attack most viewers have heard of...Use an exploit found in the company software as a starting point for the attack.Describe if you can why Anti-virus can't solve the issue customers.Perform the attack in basic.Go as deep as you can possibly go with the vulnerability/exploit.Show what the effects of compromise are.Are there further steps that can be staken? Then take those steps...Can the attack be chained with other vulnerabilities? Chain it up.Can the attack be automated to form a pattern of attack? Try to show this.At this point you should have peaked a users interest 10 fold, and maybe even scared them a little (what's wrong with that?).Now slowly turn back the clock and detail how the exploit performs its magic.Now lets detail how the attack was delivered/contrived... usually we can use a test tool to reveal how the issue was discovered.If the attack has any juicy details we can intercept, intercept them as one last detailed proof that something has been compromised/gained by the attackerNext lets detail how the attack can be prevented, and demonstrate the attack failing after the fix is applied.A complicated bug type might require a more in-depth discussion on preventionFinally we can talk about any known protections and prevention technology that can help keep computers safe.
Creating Developer Security Awareness
CREATING DEVELOPER SECURITY
AWARENESS: USING ATTACKS
• Evolving methods of communicating security problems to developers:
• OWASP AppSec Tutorial Series : Shock value, easily demonstrates risk/prevention
• I have noticed that web developers really take-to powerful/short introductions
• Michael Howard @ OWASP AppSecUSA in 2012 :
• won't work if its too long or overloads the listeners (retention?)
• best done in short presentations that can quickly explain (ie. Zest/Punch)
• Have a whole website(book?) available for people looking for more clarification
• It is hard to find good information that couples vulns with attacks, and fixes
• You can tell them to fix, but if you don’t W5 the issues, things get dropped
• Somehow security groups need to model to others what is at risk in an attack
• Remind them why we want to prevent attacks, and cite reputation issues
FOG OF SECURITY RE-ENGINEERING
• Some bugs get fixed… but the pen-testers
continually report issues that are not fixed
and probably won’t get fixed.
• Flaw is buried in the most popular feature
• You’ve performed or reviewed the
millionth assessment with bug X.
• You’ve had that 24th meeting…
• Burn out is here and even you need relief
• Its time to take an issue with
Awareness, somehow blow them out of
• Pick your darkest bug set and detail what
exploitation might look like…
PILE IT HIGH
• After working in software security you might start thinking like a philosopher:
• While an XSS might divulge a user's session cookie, and even that is a really really
critical issue to fix, certain individuals might rightly state, well a login provided to
such and such a feature has no access to anything important.
• So you see what this XSS provides to an attacker doesn't really mean
anything, because that webapp has no access to critical information assets???
• What such a response glosses over, is that exposing a User's session cookie is
only just one issue of a plethora of other possible attack vectors (via. RCE)
• Everyone knows that SecBug X is bad ass however, “they don’t know how…”
• Actually you don’t really know, lets start to build some kind of integrity here
• By debunking the arguments and rebuttals provided, we bring people closer
RAISE THE BOO-YAH
• Use attacks that have been used in
reality, and discussed in the news.
• See if you can’t pair common bug X
with this real attack payload, so they
can later look up and learn about it.
• Don’t allow yourself to make a boring
communication. Make it with pizazz!
• Get yourself excited about the
problems, by taking the training.
• There are lots of security training
groups out there (get up-to-date).
• Don’t cheap-out telling yourself I can
learn this on my own (time == $$$).
FILTER THE BS
• YouTube is great and I have seen great videos
there, but its nothing you can show your
• The is a certain way of being cool cat that
really isn’t that cool. In a year or two its not cool
• If you want the audience for your video to
actually be people who develop software you
are going to need to adapt to meet their needs
• If we don’t take developers all the way to s-hell,
then were not really taking them anywhere
• Is making it simple not your job? Then stay solo
• Look at the experts in communication do they
skirt around the issues, or aim for the heart?
GET OVER THE AWARENESS BUSINESS
• The executives talked about raising awareness
• However when it came to meeting the
expectations of your common developer…
• When I started making presentations and
videos to summarize, everything just felt better.
• After creating this video I noticed the
executives subscribed to an official set of
security awareness material
• As I look at what was out there though, I
realized I am a party of one, and really the
only one with an incentive to learn more.
• There are many hats you can wear in this
business, but which one will have an effect?
KEEP IT ORGANIC
• If you create a company directed security
promotional like this, which you can post
links to it everywhere:
• Bug Pages
• There are more chances for people to run
across it in their everyday work
• By peaking people’s interest, we are
exposing the worst of issues and trying to
steer people towards real risks.
• Helping the company to build integrity.
GET THE FACTS
• I spent time, effort, and money to chase down exploitation
beyond session cookies, because it seemed interesting to
me, and I didn’t remember seeing this anywhere:
• Research the topic
• Listen to podcasts/conference talks
• Speak to others (hardest)
• Take the training
• Can we find it in our own code anywhere? (Do it.)
• If we consider it APT-possible, what things can happen?
• By trying to attempt to understand what is attackable, we
have a better awareness of what is probable
• We will also learn about the protection others believe is there
• Focus on your attacks first. Your story.
• Everyone has heard about hacking
• We mix in legalities and $kirt the field
• I wanted to work in software devel
• I didn’t want to be a QA any more
• I ended up finding quite a few vulns
• I knew the vulns were bad but not how
• As paid employee legally this info is?
• Enlighten on these scary predicaments
PERFECTING YOUR ATTACKS
• To be honest I hate the spy concept
• But considering our industry it works
• Ensure you exhaust all your resources
• When you find that last morcel Boom!
• Aurora video I found online did it
• If I didn’t search long enough?
• After its starts rolling for you, perfect it
• Legitimate attack scenario is not easy
• Task of explaining to others is hard
PERFECTING THE EXPLANATION
• No exploitation, no explanation
• Tell the whole story and real risks
• Yes it is a bad subject, but its also work
• Practiced attack gives you domain info
• Record your video as if for strangers
• Use all the VMs/tools, and cut it out later
• Explanations demand more video/story
• After you have perfected attack and
explanations video, create a script
• Working back from this you will find
introduction tie-ins and more.
DO THE POST-MORTEM
• Mastered attack -> easier explanations
• Tie it back to reality in the simple or hard
• Show the proof of what happened
• Relate to other attacks: CJ of FB login
• In some way all attacks are the same
• Good place for lead-ins to other vulns
• Emphasize the attack line if important
• Doing this well, leads to a good intro
• I wanted to jump into the fix, but it didn’t
make sense quite yet to do that
• Make it as detailed as necessary
A STORY BUILDS IT UP
• A video that displays real compromise
should be easy to create a story for
• It also might mix with real life (A/V)
• If you get better ideas just go for it
• Redo’s are common with a new script
• Video editing software is so buggy!
• New ideas will come, weigh the value
• It is best to at least cover these:
1. Something everyone has heard/seen
2. A full exploit that hits fast and deep
3. A fast automated attack
• People should start to think differently
WHY DO WE CARE?
• They are not going to get it… So!
• Make a laughing stock of yourself
• Phishing intro: the first thing in my mind
• Later it felt sarcastic, and a good vice
• It made the problem more plain to see
• I was hoping someone would laugh,
and then run smack into realization
• That’s just it! A real XSS exploit appears
to be just like any other web page
• It is important to realize that a website
can be made to do anything and
developers are in charge of appearance
HOW DID WE FIND THE BUG?
• Are we ever asked to fix the bugs?
• Do Devs become security conscious
because they know how to program?
• Show Devs how to consider STDD
• This might lead to something else, like the
discovery of problematic ThirdParty code
• Let them know about SAST/DAST
• Detection knowledge leads to prevention
• Attempt to include your product or
company in the video
• Bring up reputation and liability issues
• Go beyond insults to engineering
• No one is perfect. We need a common
ground for discussion make one.
• Some bugs might be simple to fix
• RCE bugs are anything but simple
because the fault is in the genetics
• When dealing with RCEs go deep
• Try to use the best sources/definitions
• Provide them framework suggestions
• Map the entire issue lifecycle + fix
• RCE preventions and counter-measures
EXPLAIN THE EQUIPMENT
• Are we fighting this battle bare handed?
• Explaining prevention can be simple…
• For RCE it is hard, so go as far as required
• OWASP XSS Prevention was thorough, but
I had to bow out and exit stage left (time)
• Don’t go so deep that no one is listening
• If they don’t watch it, they can’t mock
• Make it fun, but try not to waste time
• Aim to gain the respect of your groups
• Use a Dev-possible mindset for awareness
• Create wiki page detailing equipment
• Who? Me? If not you who else can/will?
• There is lots of philosophy in business, but
try not to get caught up in the rat race
• Be prepared to justify your videos/cause
• Make your video respect worthy
• Put your own time into it, or just go home
• Having security training is good, but an
in person explanation can be specific
• Be prepared to poke holes in the other
strategies presented by management
• There is no fail in attempting to help…
• If you think your failing, speak to others!
IDENTIFYING WITH MANAGEMENT
• Accountability: is another word for this
• Luckily you are not alone. People have
been selling security to other
people, since before we had
• Look-up some of these people. Metricon
• Many reports out there to reference/facts
• Statistics not there? Use news headlines
• Make friends with the management team.
• If you’re an employee don’t shame us…
• The reason you start with report
citations, is to make it a business issue; not
THE GOLDEN BLUEBERRY
• Here is my magic word slide (Secret Sauce)
• Rethink the video so you sell it to the group
• Not management heavy? Your lucky!
• A report will help to bring it to the business
• Introduce the issue typical way (atypical?)
• Start where they are at, but carve the path
• I used vulnerability finding to put it in scope,
something that DEV might have seen before
• Every “Seminar” has a magic sales slide
• You can do it, feel the magic, believe it
• Don’t forget everyone is special… in that
they have a chance in this life (in some way)
GIVE IT A GOOD HOME
• Ask others where the best place to
showcase it is. Find usual locations.
• Some place that has high visibility
where people look all the time
• I recommend an internal location
• Don’t post it on youtube, if it is any
good it will contains privileged info
• If awareness doesn’t make people
question things, what is it doing?
• If your company is small or lean
enough, perhaps other methods
will work better. Are they listening?
• Perhaps a general video that
describes key industry issues.
• If you have created something new
• If you are really interested in it
• Make it a big deal
• Invite the dev teams you work
with, and anyone else interested
• Send them an introduction e-mail with
a good link to your video.
• Ask them to watch the video, and
consider coming out to discuss it
• Ask everyone when they want to meet
• Plan Lunch and Learn for small groups
• If you have a large group have an
open forum, and invite discussions…
IN PERSON DISCUSSIONS
• Book a good time for everyone, or
plan to have multiple meetings
• Create a slide deck that covers all the
issues they might need to know.
• We can answer questions, but if no
one has any questions, have it ALL
• From recent issues to academic
• Ask the audience questions (reflect)
• Attack – history, variations, and risk
• Exploitation – how far does it go?
• Detection – perform tests to check
• Prevention – library features etc.
• Monitoring – is it in the logs? OODA
• Protection – Policies/Controls available
• These slides can be a bit boring, but the
topic isn’t boring, try to keep it exciting
• The talk is going to reflect your wiki and
aim to completely cover the issue
• Engage with the audience
• Make sure they understand the depth
of the problems. Ask for their opinion
• What did XSS allow us to do to victim?
• Steal their cookie jar?
• Or insert a key logger?
• We want to highlight their knowledge
• If no one is answering questions, ask
them why, learn to communicate
• From my experience, not sure if they are listening
• Its like you are working with silence, not people
• The important part is that they have been told
• If they understand this… watering hole, malverts?
• We are trying to get them to think about it
• Developers who get it are really rare
• However those who do can really help you out
• Reach horizontally and vertically in your corp.
• HR can help with spreading some messages
• Alter corporate processes and remove oversights
• The whole goal here is to help the team work well
HERE’S WHAT I THINK WORKS
• If you think you have covered it
all, have you managed to cover:
• Exploitation / Explanation
• In other words, is the issue MAPPED?
• We often spew vulns not explanations
• We need to gain engineering buy-
in, where money is king, security has a
• There are so many experts who say this
GET THE PEOPLE LISTENING
• AS: Learn more about why developers
don’t want to fix the problems, instead
of debating probability of attack
• We need to be creative about how we
get Development into the discussion
• JW: We need to remember Software
Priorities According to Developers are:
1. Expected functions and features
• If we can do 1-5, then probably Security
• Ideally you have researched:
• the exploitation topics
• the corporate vulnerability history
• Stayed aware for your company:
• full-disclosure, bugtraq etc.
• or out there through other sources
• Participated in:
• penetration tests on assets
• leading the bug triaging process
• assessment/reviews on your group
• Good sources for a starting point