Hope you enjoy it and as usual if you want to talk about the content with me you can shoot me an e-mail form the contact page or hit me up on twitter @SparkleOps.
Hope you enjoy it and as usual if you want to talk about the content with me you can shoot me an e-mail form the contact page or hit me up on twitter @SparkleOps.
I got some great feedback from people at meetups and conferences that my reading list for 2018 was very helpful for them and asked I do another one this year. So here it is!
Last year had a heavy focus on everything related to my day job in appsec. This time around I am going to pick from a wide range of security topics that interest me outside my usual focus of application security and security analyst kind of reading.
The most important theme I noted in the books I picked out for 2019 show my leanings and interests towards better understanding offensive security especially red team and attack simulation.
This is primarily because I want to become become a better defender and start to think about better joint exercises and collaboration with both the red and the the blue team might look like.
Im looking to get a much better understanding of red team tactics and how the engagements play out. Typically to date I have been assisting clients in scoping and remediation of red team engagements without having eyes on a deeper understanding of how the engagements play out I think its much harder for a defender like me to get the best value working with both teams.
Same objectives as with the The Hacker Playbook above. More red team reading :)
This was a recommendation from Amazon while I was looking at threat modelling books earlier last year. Often in threat modelling training I call attention to the mix of internal versus the external threats we must consider but feel like I might not be giving enough attention to the malicious insider threat element. I think this will help me think about the way I communicate insider threats to the people I am running threat modelling workshops with.
This is purely for pleasure, I had a quick hunt around for some reading on the Dark Hotel APT but couldn’t find anything that took my interest.
Along similar lines was this on Stuxnet. I remember following along as best I could on social media and infosec news when this was happening but this seems like it will take my understands of the event up a notch. Its going to be a fun read!
Again another book for pleasure. I am quite interested to know the history behind the Pinkertons and this is where I am going to start.
The description from Amazon covers it best:
The true story of Kate Warne and the other women who served as Pinkertons, fulfilling the adage, “Well-behaved Women Seldom Make History.”
Most students of the Old West and American law enforcement history know the story of the notorious and ruthless Pinkerton Detective Agency and the legends behind their role in establishing the Secret Service and tangling with Old West Outlaws. But the true story of Kate Warne, an operative of the Pinkerton Agency and the first woman detective in America—and the stories of the other women who served their country as part of the storied crew of crime fighters—are not well known. For the first time, the stories of these intrepid women are collected here and richly illustrated throughout with numerous historical photographs. From Kate Warne’s probable affair with Allan Pinkerton, and her part in saving the life of Abraham Lincoln in 1861 to the lives and careers of the other women who broke out of the Cult of True Womanhood in pursuit of justice, these true stories add another dimension to our understanding of American history.
I learned about Joe Navarro when I was an avid and regular tournament poker player looking to get an edge on reading body language and people.
I read several of his books and spotted this, I am going to read it and see how it potentially supplements the books I read last year on social engineering.
I read Robert Cialdini Influence: The Psychology of Persuasion last year and found it a real eye opener. Especially stacked with the other books I was reading on social engineering at the time.
I have referenced Sidney Dekker in previous engineering culture blog posts around blameless post mortems and just and restorative engineering cultures.
A deeper understanding of failure seems like an absolute no brainer for anyone building and trying to secure complex systems.
A very kind and thoughtful present from my twitter #HackerSecretSanta this year from @keithrozario. I feel like the infosec world is lagging a bit culturally behind our SRE and ops friends. I want to build the best bridges I can with these teams and part of doing that is ensuring I continue my education on Devops culture.
Very interested to hear about the books you read over the break and what you plan on reading in 2019. Feel free to reach out and e-mail form the contact page or hit me up on twitter @SparkleOps.
As an Application Security Specialist, part of my role is to help teams with engagements ensuring they get a well considered and executed penetration test. Its important teams can not only understand the report findings but also learn from them and roll those learnings into their coding standards and come back stronger for the next audit showing their pen testers their real value has been understood. For this you need run the right testing first and that doesnt happen the real value is lost.
I have worked with engineering teams who have a reasonable level of security maturity and other teams who are just starting out on their journey in writing more secure code.
It struck me one day that both high and low maturity level teams really struggle with working closely with external penetration testers and in running a good penetration testing engagement.
I started to think about what was common across all the teams I have worked with and what could be the problem, and looked a bit into my own past life as a QA tester for answers.
I figured out what it was one day when I was thinking about a particular engagement I was doing testing some gas power-plant infrastructure stuff for a client remotely. I shipped a build to them with the ultimate confidence our engineers have provided excellent software that both met the specification and was robust and my testing was solid evidence this was the case.
This was back in around 2007 where the way of producing software where I worked was the waterfall methodology. As a QA test engineer I was not really involved in planning, system design and very little in development.
Testers would instead be brought in at the very end of the project to test as much as possible and triage the issues at close out of testing in the hopes they could sign off a build and drop it into the clients user acceptance testing environment for their review.
Without all the right context I had tested to the spec and done some fantastic automation and performance testing. Based on my understanding from the spec I thought we had done a great job. I had almost completely perfect traceability and test evidence in the reporting to back it up.
Sadly we had missed several very important issues which showed up instantly and lead to a rather intense call with the client not long after pushing a build to their user acceptance testing environment.
It turned out while I had exceptionally great coverage of the specification and done well considered exploratory testing I was not an expert in gas networks and accordingly had missed some pretty critical issues.
It was a matter of context handover. The client had never worked with a professional QA tester before and didn’t understand really what I did and what I needed to be given in order to go on doing well in testing their system. I was also offsite so not really part of the internal team that was building things from their end.
Missing the kinds of things I did was entirely reasonable given this and to course correct the client made up a package of documentation, got me some business and technical support contacts and ran some peer testing sessions with me that completely fixed this.
Much later on in my software QA career and having been part of high performing agile teams who were shipping to production 10+ times a day I knew one of the many key elements that helped these teams perform building great software at such a cadence was having fast feedback loops and con conversations throughout everything they do. It was all about sharing and understand each others context.
Yet despite all the evidence pointing to successful engineering teams are those teams working much closer together across the disciplines and having especially QA and Security ‘shifting left’ throughout the entire SDLC , we are still doing security right at then end.
Like its waterfall all over again? Are we throwing a build over the fence to penetration testers offsite somewhere and asking them “Did we build this securely?”. It certainly seems so and I feel their frustrations mirror my own during my days of testing software built that waterfall style.
I have seen how much this is damaging for both the engineers / defenders and the penetration testers. The context is not handed over as well as it could be and the penetration testers aren’t always getting the level of support they need to execute a great engagement.
I set out a few years ago to start fixing this and have written this post (and have done a few conference talks) to help share what I learned help close these gaps and make life better for both teams.
Understanding the engineers perspective on pen tests
Firstly id like to talk about one of the most significant gaps between engineering teams and penetration testers. Often being in two different locations and handovers done via short calls and email both teams do not get the opportunity to have a well considered / meaningful hangover to understand each others needs.
It feels like the pen testing engagements are never forecast and outlined to the people building the software, especially their need and to be ready and supportive of penetration testers. The pen test ‘sneaks up’ on engineering teams and before the engagement its always a mad rush to assemble the minimum pre testing requirements while also rushing to meet sprint deadlines and ship.
Engineers have often never been told what happens during penetration testing and do not understand the kind of context and support that would give pen testers the right context and information to execute your best testing.
Further to this some teams have a certain fear or anxiety around their work being audited by a security professional. Mostly likely because of the potential fallout and delays created by receiving a report with critical finds. That and in many causes the engineers are facing an audit on a skill set they most likely have received minimal to no training on.
It results in engineers not having the headspace or inclination to do a great job to handing over the penetration testers.
Often the result is a penetration test thats not sufficiently scoped or supported and everything suffers from execution to the reporting and the remediation.
Penetration testers trust me teams do struggle to work with you and understand how to best support you.
If you can respect this and really help them with what you need they will start to understand you are a teammate who they can work to ship a secure build together and not something to be fearful of.
Engineers and defenders, if the penetration testers get more involved you need to welcome the penetration testers into your team and support them every step of they way.
So how have I helped teams despite being often seperate make this stuff work better?
Scoping the engagement
Make the best use of a kick off call. Have engineers and QA people especially be available to walk through the application and requirements on a brief call with the penetration testers. A screen sharing sessions can work really and help both side consider some potential pain point to investigate further.
Lets get good at asking each other leading questions
“What are the most important aspects of this system”
“What are the first things you’d attack in a system like this ?”
Then perhaps talk test approach, “Anything else I should look at?”
Sense check both teams have a mutual understanding of both the business as much as the technical elements of what you are trying to release
Non standard penetration testing engagements are ok! If your building a risky feature or something new with lots of unknowns why not ask for a split engagement where a code and design review happens at 20% complete? Work with your engagement manager to scope the test that makes sense not just testing at the end.
Can you have onsite testing?
This is one of the most effective ways I have helped teams fearful or new to penetration testing overcome this and get a good handover of context done at the same time. Any expense on flights and accommodation pays for itself 10 times over because
Especially if teams are new to penetration tests or struggling they will begin to understand the aims and needs of penetration testers and start to build a good relationship with them as team mates.
The most effective place to have operations, technical and business support is by being in the team building the software.
Fast Q&A / feedback loops as testing is being executed for both teams.
Know testing is coming and build the pre testing requirements early
Book and socialise the penetration testing well in advance, even consider adding it as a calendar item for the team members so they are mindful this is an activity they need to support and be involved in making a success of.
Have the team build out a well considered documentation package as part of pre testing requirements your Penetration testers ask for. Include anything that helps them understand what you have built. Examples include:
Network and component diagrams, A good overview of the environments
Solution architectures and specification documents
Early source code and issue tracking access
Early access to the test / staging environment
Two sets of testing credentials for every type of system user. Ensure they users are not touched by other employees in your business during the testing
Support each other to run a great engagement
To run a great engagement the teams should commit to supporting each other.
Engineering leads should specify a point of contact who will ensure they have business, dev, QA and Ops people on stand by
Make it your priority to unblock penetration testers during engagement if they are missing context or locked out / are missing access
Penetration testers should for longer engagements make sure they check in with the teams. Especially if there is a high or critical find which is going to impact delivery or worse in known to be in production.
Make the time for remediation and involve the penetration testers
Time for remediation needs to be budgeted for and engineering teams need to be taking advantage of any post testing review and regression testing activities on offer from the penetration testers. Dont be afraid of the report findings, get their help to understand them and improve the coding standards and education in your team to come back stronger for the next penetration test.
Engineering teams must defend the right to make changes to ship secure product. Put all finds into tickets and make a commitment to address them in order of risk.
Use the provided opportunity to talk through finds and fix approaches with the penetration testers
Developers participate in regression testing / code walkthroughs if they can.
The most painful thing for me as an Application Security specialist and no doubt our penetration testers is seeing different teams in the same company make the same mistakes. To show Penetration testers you are able to realise their true value to you beyond just doing another engagement and come back stronger next time.
Dont lock up the Penetration testing reports. While these are not for everyone in the business to see I encourage the technical report be shared across all engineering teams and ops / SRE teams too.
Applaud quickly recovering from and remediating issues just as much as not having them in the first place. While a clean test report is nice when you have finds you fix you are learning.
Track back report findings to support articles and entries in your coding standards. Help the engineers get all the support they need to be educated and not repeat history.
I hope these ideas can help you and your teams work closer with external pen testers. I will have a follow up blog post containing the YouTube video of the conference talk that supports this post in due course.
As always id love to hear your thoughts and any ideas you have be it from the engineering side or as a penetration tester. I feel we must get things working closer so both teams have a much better experience and deeper learning.
Best way to do this is to reach out to me on twitter @sparkleOps.
I’ve been doing some conference talks here in New Zealand and in Australia about removing the common misunderstandings and roadblocks I see defenders and engineering teams have working with external penetration testers and getting these teams working tighter.
James and Dan asked me if id like to have a bit of a more general chat about penetration testing with a bit of a QA focus I was happy to oblige (Show link).
Generally on the show we cover off:
What do you mean by penetration testing? What should it cover?
Can I do it myself? What is the advantage of an external pen tester?
What should I do to prepare / make the best of a penetration test?
What kind of things can I do to support our external security testers? Especially how do we handover the right context?
I want to learn more about penetration testing or become a pen tester, where do I turn?
How to choose a penetration testing company, should you use the same one every time or rotate?
How do your build a productive long term relationship with your external penetration testers.
I hope you all enjoy the show and it helps understanding penetration testing and give you some ideas as to how you can work tighter with penetration testers.
As always you’re welcome to send me an e-mail or chat to me on twitter (@SparkleOps ) if you have ideas you’d like to share or feedback.
Super proud to announce I’m heading to Perth later this year to talk at the Security BSides Perth conference about getting closer collaboration between defenders, engineers and external security testers. The talk is entitled "Caring for our pen tester friends”.
Quality assurance teams are becoming more context driven and collaborative. QA Testers are now needed from design through to supporting their applications into production.
Yet we still ask external security testers to test our applications engaging them at the end just before we ship to production. Often armed with very little handover we ask them “Did we built it securely?”.
I see a big gap between external security testers and development teams, its making life hard for both teams. I also see the damage it does to good security testing. Its time to bring these two team closer together and start take better care of our pen tester friends.
This talk covers advice for both engineering teams and their external penetration testers on collaborating more, ensuring the right context is exchanged and the teams work together for better security testing outcomes.
Looking forward to it and all the other talks released so far. Its going to be an outstanding weekend. The full line up is posted here.
If your coming along do come say hi :)
If your interested in physical security, red teaming, lock picking and being with some friendly and inspiring hackers and infosec people then OzSecCon is for you. Everything about this conference was well run and I had an immensely enjoyable time. A huge thank you to conference organizers, ill be making the trip every year its on <3.
It was mentioned in the opening notes that the OzSecCon conference was pleased to be attracting and including in the more "digital" security folks and sharing the red team and physical security world together . It got me thinking a bit that besides the odd talk and a lock pick table at some of the security conferences I have been too there isn't much bringing these two groups. Well mission accomplished! From hanging out at the breaks and after parties it definitely attracted a wide range of people from all professions and interests :)
The conference was run at the Melbourne Polytechnic West Heidelberg campus and allowed the conference attendees access some exceptional spaces including workshop facilities and tools which would normally be well out of reach for the average hobbyist lock picker all with then right supervision and people to help you use the facilities safely and learn if you were new.
Conference talks wise I was super amped to see @HydeNS33k from Walmart keynote and Auras Logan Woods & David Tredger talks on red teaming. Its super valuable for someone on a blue team to hear these war stories and get a better insight into the mindset and tactics employed by a red team during an audit.
Having this perspective helps me especially think about how I talk to other people if we are doing security awareness messaging / training being armed with some real world examples of things to be looking for.
@attacus_au gave an excellent talk about facial recognition technology and some of the initiatives people are working on to defeat it. Beyond camouflage (I was happy to hear the Vaporwave aesthetic is great for this) and other techniques this included a call to action to speak out against using this technology in ways that overreach and hurt our rights to privacy.
I had gone to OzSecCon get some learns as a 'newbie' lock picker but never once picked up an actual lock. That's because aside from the talks I ended up spending a significant amount of my time at the Google tamper evident seal challenge.
I've not done many CTF's like this before and was instantly hooked. There was an exceptional vibe of people working on different ways to beat tamper seals, steal items from mail bags or move seals from one place to another undetected. It was so much fun!
I was pretty happy to have placed 10/70 contestants in the tamper seal CTF and in awe of some of the people further up the ladder especially (including a few fellow Kiwi's , congrats on 5th @Phage_NZ).
There is a fantastic write up and walk through by conference speakers Mos and Boo you should checkout if you were playing too.
A huge thank you to Google and hosts who were on their feet all weekend making this a great competition and event. Kudos goes out to: Ben Low, Grace Nolan, Evengy Shatokhin, Tom Hennen, and David Wearing, you made my conference!
Well done OzSecCon. It was fun, safe and I learned stacks and had a absolute ball. Also shout out to the team who put a huge effort into the electronic badge, as a ex hardware guy I know this was huge ... its my first electronic hacker con badge so its hanging somewhere special at work. See you next year.
Much love @SparkleOps
I get real satisfaction out of running threat modelling workshops because after the session I can almost immediately see the results in the changes that get made in design and overhearing some of the conversations had around the security controls our applications need to have in place *before* we build them.
I start threat modelling workshops by leading a discussion about what the term vulnerability actually means, stealing the definition from google:
"The quality or state of being exposed to the possibility of being attacked or harmed".
By that definition vulnerability is being exposed and there is only a unqualified potential of being attacked.
The key point to note to the class is usually an attacker needs to gain something from attacking you. It might be financial gain, something ideological or a just a display of skill and bragging rights. The question is what is their motivation? Why do this?
The exercise of threat modelling will help us learn how we might be vulnerable but also help us understand the threats in terms of who, for what reasons and to what impact an attacker of their ability could have. We can then start to make well reasoned decisions using our limited resources to best defend our people and systems.
When we come to the who part of our threat model having a set of 'security personas' to select from helps us in the exercise of thinking about the types of the people, their abilities and motivations and perhaps look at the likely approach of multiple security personas on the same vulnerability.
When tasked with thinking up some examples the class will often create security personas based on things they've seen or read about security incidents in the media or even in TV series or movies. This means initially your class might be saying we need to prepared to defend against highly skilled hackers or governments so it’s Fsociety or Mossad that are our problem.
This especially for a less technical audience with little to no infosec exposure is reasonable as while we might be security professionals who live and breathe this sort of mental exercise its likely your class does not.
You need to help people learn about the more realistic threats like, insider threats, an integrator getting compromised or the non malicious genuine mistakes made by your staff like security misconfigurations or loosing a company laptop. Once you help them get into it the range of threats the team needs to consider during threat modelling is almost always much wider then they'd probably initially considered.
Unfortunately in my experience during workshops some members of the class will tag a certain person, team, product or vendor they work with (probably not present) as a security persona as in their eyes they are to blame for the vulnerabilities they know about and thus a called out as a threat. This is toxic and from the very outset I make it clear its unacceptable to do this in the workshop.
So how do I overcome these two problems? Well you need to give your workshop an engaging set of characters they can kick off great conversations with, build a story around and then invent a new set of security personas to take forward with them for the rest of the workshop.
For this I’m using sets of images of Funko pop collectible characters and asking the class questions like “Who is this?" and "Whats their skill set" and then "What are their potential motivations?" to help them imagine a story and build a security persona.
Ill give you a few examples and the kind of story we might attribute to a selection of these characters.
It’s fun for the class to hear the stories their peers invent for your selection of these characters and what kind of resulting security personas get put forward. Perhaps if your leading the class be ready to offer some security personas of your own for a few of the characters if things get stale.
Once you’ve done this you can start to think about these security personas might go about attacking your systems or people.
You can ask questions to spark people’s imagination like “How is Muttley going to be different to Loki at approaching social engineering?” or “What happens when Grumpy bear steals Tonys laptop?” to encourage your workshop to think through various scenarios and hopefully unearth even more vulnerabilities.
I hope this novel way of building security personas helps you either consider the kind of security personas to include in your threat models or in your teaching others to threat model. Its important the process is both engaging and done in a safe positive fashion and I think this approach really works great.
I am always looking for ways to improve the workshops I run and how to engage and teach people about application security, so I was pretty pleased to get this reply to the tweet stream that spawned the blog post from @ladynerd .
I don't think I have seen any of the Tinker Bell movies. So for homework I guess ill be watching them to answer this one and give some consideration to how our own biases could impact the the security personas we create.
If you have any tips or comments on how you help people consider the personas in their threat modelling id love to hear from you. Hit me up on twitter @Sparkleops.
Banner art credit Tony Fleecs https://www.tonyfleecs.com/ 💖
InfosecNZ is a slack community for those in New Zealand working in tech or information security to network learn and share on a wide range of security topics and do our bit to help grow the security community in New Zealand.
We have over 350 members discussing offensive and defensive topics like:
Come say hi and introduce yourself!
Each year Verizon’s security team and BI analysts produce a yearly Data Breach Investigations Report (The DBIR) which provides analysis on over 53,000 security incidents and 2,216 confirmed data breaches.
It’s an exceptional breakdown of current and emerging cyber threats accompanied with an executive summary on how they impact various industries.
The ‘things to think about’ summary’s for each industry are a great reminder while companies are subject to highly sophisticated technical attacks a significant volume of incidents and breaches occur by attackers exploiting low hanging fruit exposed by misconfiguration of systems, misuse or poor handling of customer data and failures to apply the security controls and hygiene mandated by relevant compliance frameworks and best practises.
I strongly suggest you have a read and share with your engineering, ops and executives inside your company or organisation and encourage discussion on the findings and how the relate to your security roadmap and posture.
You can download the full report here. A huge thank you and well done to the Verizon team and all the contributors this is a very helpful resource for the security community.
Hey everyone, wanting to give a bit of signal boost to the OWASP NZ day next week.
OWASP NZ day is a free day of information security talks and workshops with some excellent speakers from all across the New Zealand tech and information security communities. OWASP NZ day is being run on the 5th of February at Auckland University in the Auckland CBD area.
Registrations are now open and you can secure a ticket by heading over the to conference page.
OWASP days are a great chance for people in all roles and levels of experience to learn more about a wide range of topics in information security. OWASP is not just a day for devs or security professionals. Project managers, agile coaches, designers, testers and everyone in between can get some value coming along (and asking questions!)
We have an amazing security and tech community in New Zealand who love their craft and love sharing with and teaching others. With a more diverse range of folks in other non security roles turning up and asking questions it helps infosec people think and reflect about how we might better help work with and secure the people we work with. Its win win.
If you know someone who is shy or unsure if this is for them, encourage them to come!
You can review the list of speakers here. Hope to see you there !
One of my goals for 2018 was to read a wider range of books for my professional development and I have set myself a target of at least 10 books i'd like to have read before the year is out. Then blog about my learnings from each book here.
Below is my hit list and I have put a little something about each as to why I picked it.
This year I am starting a new role as an Application Security Specialist where I have been hired to assist development teams build security into their agile development process. I believe this will give me excellent foundation to really know im working on the right initiatives with our software teams.
Im working with agile teams to run STRIDE threat modeling sessions with the aim to better understand the security objectives of their applications and design out some potential flaws early rather than having penetration testers find them at the end.
The first cut of this framework I did I got a lot of help looking at slides and conference talks from Adam so this book was a natural choice to get some learnings and greater understanding on the topic.
This was one of a few recommendations I took from the Red team blog - Red teamers bookshelf. Im hoping this will assist me in running blameless post mortems with teams and in my own reflections throughout the year.
The next few are all around social engineering and the human element of security. Last year I started with Social engineering - The art of human hacking by Chris Hadnagy. I absolutely loved it and cant wait to move on to this next book.
One of my mentors suggested that if im going to read most of Chris Hadnagy's books I should look to get an alternative perspective and Kevin Mitnick would be a good way to round out my reading here.
More reading under the social engineering umbrella. Another recommendation from the Red team blog - Red teamers bookshelf.
Another from Red team blog - Red teamers bookshelf :)
I want to continue learning and understanding Devops culture and exploring the avenues for collaboration between security and SRE/ops teams. I know this came recommended from SRE engineers who read it at my last company.
Lastly the Phoenix Project, another book which comes as highly recommended from the SRE lead at my previous job. I've decided to re-read this as it been a while and found it have me immense value the first time through. Again it’s good to think about how you and your security team relate and function with in the rest of your business.
Whats on your reading list for 2018? As always keen to continue the conversation on twitter @SparkleOps.
Netsafe New Zealand have built an amazing new chatbot called Re:scam. You can have Re:scam reply to scam and phishing emails on your behalf using a variety of false personas that all create a long and ultimately pointless conversation wasting the attackers time. Watch the launch video below.
Follow along on twitter at @rescambot
Initially it look like Re:scam is targeting 419 scammers and not malware spammers or other types of phishing. Will be great to see how this evolves. Well done Netsafe NZ!
Keen to hear your thoughts on this, good idea? Maybe not? Have you used it yet to annoy a prince with some complex money issues? Let me know @SparkleOps.
I have been thinking over the content and structure of the security awareness chats I have with staff, picking out the things that are working well and those areas which need some improvement.
Im still working hard on improving the parts where I talk about social engineering, especially phishing. Phishing it turns out is a really tricky topic to cover well without it being loaded with fear. We are after all talking about really malicious people praying on our personal weaknesses and vulnerabilities to trick us out of information or infect our computers.
I have in the past made the mistake of focusing too much on conveying the lengths and methods an attacker might go to in order to deceive someone. I think it ended up being counter productive and not a risk a user would feel they personally would be subject to.
Now days I usually talk about fake DocuSign requests and some examples of Paypal and Apple ID account as more generic phishing attempts as opposed to targeted phishing. Even the more generic examples are nasty enough and illustrate how if a person was not on their guard they might click through and get their computer infected or lose control of an account.
It conveys the threat well enough, so job done? Well no. I have only at this point only explained the potential harm and some of the warning signs.
Im mindful after showing some of the better crafted examples you can be fairly certain there is now an even bigger fear brewing in your audience, that they might be the ones that get caught out. They failed to spot the con and clicked that malicious link. What would they do if this happened to them? Panic?
It’s really important to explain everyone is vulnerable one way or another. No one is immune from making an honest mistake while tired or under pressure. How can we assure our staff everyone including us the security professionals get baited every once and a while?
I have decided in my next session I am going eat some real humble pie and to start telling people I work with how I got phished recently. How one late night I ignored some of the signs I teach people to look for that somethings not right and gave up my e-mail and mobile number to a phishing scam.
It was a Thursday night, I had my feet up on the couch listening to some music and was flicking through Instagram on my phone. I was really tired, It had been a really busy week. I saw a promoted advert for Ben and Jerrys ice cream which apparently is opening up stores here in New Zealand.
For avery limited time Ben and Jerrys were offering a select few people the chance to grab up to 3 free tubs of any flavour of ice cream provided we shared it somehow on social media. I love ice cream and I sure love twitter, what luck! Im perfect!
The advert was well designed and the branding looked absolutely like what I had seen in other Ben and Jerrys stores I had been to in Singapore and the US. Just enter your full name, email and mobile number and we will send the voucher codes out it said.
There were a few things right away that if I was paying heed to my own advice id have at this point wanted to reconsider engaging with this offer.
1. Instagram are not perfect, they like many other social media sites will take ad revenue from anyone. Including people running a phishing scam. Just because its from Instagram there is no guarantee this is legitimate.
2. This was a limited time offer, appealing to scarcity and creating a sense of urgency. Get in quick before its gone!
3. Thats a lot of personally identifiable information to give away for 3 samples of ice cream.
4. The amount of genuinely free lunches that exist online (none).
5. This popped out of Instagram into a browser, is everything still looking ok?
Now in my defence I was really looking forward to this ice cream. I was going to pick it up and enjoy it with a bit of Netflix on the weekend. This is what I was thinking about when I blasted right past all the warning signals and gave them all the details they needed.
Moments later I started getting SMS spam and spam messages starting to pile up in my inbox. It very suddenly hit me what id gone and done. Free ice cream? Brendan you idiot! I went back to the Instagram post and saw a bunch of other unlucky ice cream fans warning people in the comments this is a scam and not to engage.
Social engineering is something I love learning about and hope to one day participate in some social engineering CTF contest and maybe even some trainings.
While no expert in the subject by any means I know enough to give other staff their security awareness training in what they should be on the look out for. Point is if anyone thinks this interest in the subject gives me some kind of elevated immunity from being conned I am sorry to admit turns out offers of free ice cream are enough to do the job on me somedays.
I felt pretty stupid. Really stupid. Fact is everyone can be exploited and do silly things under pressure or when they are tired and there is no real shame in getting baited. This needs to be part of the security trainings on phishing as much as coverage of the motivations and methodologies of the attackers your helping your people become aware of.
Understanding it happens to the best of us is important but it also needs to be backed with an assurance if it does happen the right support and assistance will be blamelessly in place and provided for people who ask for help when it goes wrong.
I filed an abuse report to Instagram and my ISP/telco to get help. They both helped a lot in stopping the spam id signed myself up for. Make sure your people know the security team is here to do the same!
Will be interesting to see how sharing this story of mine goes. Im willing to bet an open admission of my own mistakes and how I was able to recover quickly will help take the heat and fear out of potentially being phished at work. Understanding the threat, knowing what to look for and having actionable steps if things do go wrong is what I think makes for valuable secuirty awareness training.
Do you do secuirty awareness sessions in your company? What works for you and your staff when explaining social engineering topics?
Keen as always to continue the conversation on twitter @SparkleOps .
In May this year Intel announced a serious remote exploit vulnerability in their Intel Active Management Technology (AMT). AMT is a a hardware and firmware technology for remote out-of-band management of computers. Intels full summary of the technology and the vulnerability is here.
If the Intel AMT feature was not something in use by your organisation it was simply best to patch then disable the feature. There were however in some cases no patches provided by some hardware vendors.
Good news! Intel have updated their advisory to say more firmware updates available to address Intel AMT vulnerability you can read that advisory here.
If you were left with machines in your fleet unpatched because of this nows a great time to go back and check for updates.
You can do so for some of the more popular vendors here:
DocuSign have confirmed a breach where according to their forensics attackers gained access to one of systems enabling them to harvest customers email addresses and then use them to launch phishing attacks.
Brian Krebs has done an excellent write up here
If regardless of you are a DocuSign customer or not you will want to brief your IT, operations and customer support people to be alert for inbound phishing e-mails to staff and be potentially also be ready to field reports from your customers and any 3rd parties you deal with that may be receiving these malicious e-mails.
Now is an excellent time to also send a security awareness message out to the rest of your business that details some short and concise advice for your users to report anything they get to the right people running incident response.
A few updates as things have unfolded further over the weekend. My original post when Wannacry aka wcry ransomware first dropped is here.
Firstly and mostly importantly lots of critical infrastructure, hospitals and telcos which have legacy Windows 8 and XP machines are getting emergency support from Microsoft. Bravo Microsoft this is a great step to help defenders mitigate this threat.
Microsoft have also released this customer guidance
If you run these systems in production I have the direct links here thanks to this posting from Threat Post
Download localized language security updates: Windows Server 2003 SP2 x64, Windows Server 2003 SP2 x86, Windows XP SP2 x64, Windows XP SP3 x86, Windows XP Embedded SP3 x86, Windows 8 x86, Windows 8 x64
It seems the best mitigation is patching as soon as practically possible. If offlining or patching a machine is not an option then disabling SMB v1 is the next best thing.
Dont forget your change control and testing though. Nothing worse than accidentally offlining your business in the name of keeping it safe from potential threats.
Dont expect Wannacry to be a one off. Its exploiting a serious windows vulnerability and the chatter I see from security researchers I trust suggest its trivial to repackage and launch additional waves of attacks. We have already seen a wcry 2.0 version with the kill switch the original iteration had flagged off.
Im following these sources to help me follow this incident and ensure I have the right information in front of me to know our response is solid:
Thats all for now. My thoughts are with everyone incident responding to this. Its going to be a very rough week.
Woken up this morning to hear there has been a significant outbreak of ransomware known as Wannacry hitting windows machines which haven't applied the MS17-010 patch .
Ive copied the executive summary in the gist linked below as it perfectly contains the needs to know on this (credit to the rain-1 who stood this up).
Im following these sources to help me follow this incident and ensure I have the right information in front of me to know our response is solid:
So its time to help support your friends and family ensure thier older windows machines are current with their patching and if your in tech, read up and share with our IT departments, SRE/ops folks to ensure patching is rolled out across your fleet of windows machines.
Excellent news! The first Security Bsides conference for New Zealand is being run this year in Wellington. I figured id pop up a post giving the basic details.
Im very keen to head along and perhaps do a lightning talk this year, provided work and life commitments don't stop me.
Will be a super welcome opportunity for the community to get together and share learnings and catch up.
I wanted to talk about the recent LastPass password manager exploits reported by @taviso and the negative perceptions it may create for LastPass as a password manager for its users.
Its likely people who don't live and breathe the world of software and security see exploit reports like these and without context are left feeling their security tools are leaving them vulnerable.
Vulnerability - 'The quality or state of being exposed to the possibility of being attacked or harmed.'
I think it's important to talk to people about security flaws, the responsible discourse process and how the efforts put in by researchers like @taviso are of real value improving the security tools like LastPass.
Password managers like LastPass are now an absolute essential for both home and business users. The DBIR data breach investigations report produced by Verizon's enterprise security team each year shows us that still one of the leading factors in users accounts being breached was poor password management and lack of 2FA being implemented.
These breaches were likely not the result of a highly sophisticated technical attack but attackers taking advantage of what is essentially low hanging security fruit. All of which can be mitigated if users are educated on use of a password manager and 2FA.
But if the password manager they use is being reported as wide open to being exploited and their passwords stolen of what use is it? Well thats the issue, The discussion and reporting surrounding these exploits walks right past some very important considerations and context users needed to make a judgement call on how vulnerable they really are.
So how do we address some of the typical concerns and put things into proper context for our people?
We want to start with the possible misconception having security flaws reported is a huge failing on LastPass's account and we should all be switching to another password manager product to continue being safe.
Its important to explain to users that all software has bugs and security faults and that its unlikely another companies password managers product is free from similar such issues. While companies will conduct their own testing and engage 3rd party security testers to review their products things can still get missed.
Its follows then that we should also aim to spend some time explaining the work security researchers do what a responsible disclosure process looks like. When issues are disclosed to vendors in this manner by researchers users are not being made instantly vulnerable to the exploit but instead the researcher is working with the vendor so they have an opportunity to fix the issues and push a fix to users. This is the case with the exploits been reported to LastPass there is nothing malicious going on that places them at risk.
What will help people determine if they are at risk is knowing how we expect vendors to behave during such a disclosure. Vendors who are transparent about confirming the issue and quickly turning around a fix like LastPass has done should help users gain confidence in the software products and the security maturity of the vendor.
Vendors who are not communicative, take significantly longer than the grace period to turn around fixes or respond with threats of legal action to a responsible disclosure are more likely to have a product or service that isn't being well managed with a mature security program and this is what is more likely to place them and their accounts at risk.
Armed with a bit of education around responsible disclosures and some detail around the response from LastPass I'm confident in telling my users LastPass still provides them the protection they need to be safe at work and at home.
While the LastPass exploits reports are still fresh and in the news its a great time to reach out to your users with a security awareness message on all of the above and provide that context that I feel is often missing when things like this happen.
Additionally in your messaging explain that if passwords ever are compromised the second layer of protection they have in 2FA is what mitigates this if something does go terribly wrong. Help them set it up if they don't have it turned on.
Perhaps also consider showing them the haveibeenpwned service run by @troyhunt so they know if sites with no 2FA protection are breached they can quickly go and generate a new strong password before someone malicious can compromise their accounts.
Our willingness to provide education and support in making these tools work and putting the risks in the right context and perspective when they arise will really help users feel a lot less exposed and vulnerable.
Interested to hear your thoughts, hit me up on twitter @SparkleOps .
Been a while since I have posted up. The first 6 months of my new security role have been exciting with lots of learnings to share.
I thought id share the security slack channels we are using that help us as a team and promote a healthy engaging security culture.
We created this channel as a way for employees to share anything that concerns them with the security team. Using slack for this over other ways of reporting issues also has the added benefit that other employees can also see these reports and be alerted too. Often we get multiple confirmations meaning we have a better list of people to talk to right away.
We can get reports ranging from strange behaviour on users machines, phishing / vishing attacks or issues with physical security. The key here is employees are welcome to report anything, nothing is considered too trivial.
They can be assured when they post they will get timely and supportive response back from the security team.
Best of all suspicious activity gives us the chance to give people praise for reporting issues and handling incidents in accordance with the security awareness training they did with us. We always sign off with 'Security is team sport, and your reports are helping everyone keep safe'.
Periodically I summarise events reported back to our general channel to provide a security awareness message and a concise reminder of what to do if employees experience the same kind of problems.
We do have other means to report issues (Phone, e-mail, a report an issue form) but so far this channel has been the way thats been the most engaging and rewarding for both our users and the security team.
#Vuln-Alarming (Vulnerability alerting)
I have a vulnerability alerting channel in which we have subscribed to all our cloud tool and vendor security RSS feeds (using /feed).
We have the security team, our SRE team and anyone else who is interested to see alerts from vendors and the vulnerability alerts updates provided by groups like US CERT.
Again multiple eyes on these feeds has been very positive. Typically the security team work with our SRE team by having a simple emoji voting system to signal the status of various updates that have been posted in this channel. 👀 for 'Im reading this update , ❗️for We have an issue we need to address and ✅ for Patching is done / No issue ' all clear '
If something warrants it we can briefly triage in channel or elect to have a chat / quick meeting.
We also pipe in alerts from the defnd.io tool we use made by @safestack . This provides us with vulnerability alerting on a huge range of cloud tools, and any changes to these cloud tools terms of service / policies we may want to be aware of. It also scans for domain names similar to those of which we own so we can be aware of potential phishing attacks launched from them much sooner.
We of course have a general security chat channel open to all. Mostly to discuss security news items which employees wish to share and discuss with others. The theme of multiple eyes on and shared learning continues here.
The very important tip I have to offer here is watching for articles posted or people giving out poor security advice and practises. I watch this channel closely for this and try in a non combative way to make contributions that put people on the right track.
Once such example of this was discussions around recent vulnerability disclosures in popular password managers and SMS 2FA authentication. While granted some the flaws exposed were quite glaring the discussion in channel created the impression especially for some of our less technical users that password managers and 2FA were broken or not effective an means of protecting their accounts.
We had to reaffirm that while nothing is perfect both password managers and 2FA are absolutely essential and highly effective measures to have in place for the type of threats that face the typical user in our company.
So moving on to some of the channels we use that are specific to the security team.
#Security_unplanned (Private Channel)
This is trick I picked up from our awesome SRE team. We have a private channel where members of the security team can quickly post comments outlining any unplanned work thats come up.
It can be user questions, requests or noting that something has not gone to plan and needed a bit extra work to get done.
We periodically review the channel history and create a summary of these items. It gives us insights as to what opportunities we have to build new run books or wiki articles, add training or generally automate something thats taking up our time.
Especially if its something thats a recurring need for our users we can build something to help the users help themselves.
Many of the tools we use can ship logs to a log store like Splunk or Sumologic which we can in turn have a slack bot alerting on events of interest to us.
Its still something of an experiment right now but so far it has been a real help to us. Again we hope to expand upon the quality of alerts by having it include the associate run books or useful links when an alert triggers.
Each incident response has its own channel with a descriptive title that includes the date in the channel name.
Besides the obvious communication and transparency advantages for incident responders we also can use the timeline of the channel to help us construct our blameless post-mortems. Once the incident is resolved we can conduct our inital discussion and talk about our planned mitigations before we publish the post mortem to the wider business for review and feedback.
Its been very beneficial to retrospectively look at commonalities between incident responses of the same kind. Especially for say phishing attacks where we can start to look at who was targeted and how. We can use this information to help refine our security awareness messaging and training for our users. Give us ideas on improvements to the run books and incident response plans we maintain to deal with such an incident.
#Security team channel
Lastly a few things I wanted to share around our security teams channel which I think have been beneficial.
We share our teams mission and goals for the week in channel. This helps keep us focused on the results we want to achieve week to week but had the added benefit others can see what we are working on too.
Its great for engineering teams to see the upcoming penetration testing or gain visibility on security reviews we are conducting.
I have just started to at the months end quickly review the work we have completed and post up a summary of the security teams wins.
Its really positive to take a brief moment to celebrate the things we are achieving as a team. Successful incident responses, improvements to training and security awareness communications are the kinds of things we want to call out and be proud of.
Keen to hear some of the things you are all doing with slack to help your security efforts where you work. Hit me up on twitter and say hi @SparkleOps :)