Books! Google isn't the only source of information
•Transferir como PPTX, PDF•
1 gostou•742 visualizações
A presentation at the Jisc security conference 2019 by William Macleod, senior cyber security specialist, University of Strathclyde.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Books! Google isn't the only source of information
Semelhante a Books! Google isn't the only source of information (20)
Mais de Jisc
Mais de Jisc (20)
Último
Último (20)
Books! Google isn't the only source of information
- 1. Books! Google isn't the only source of information William Macleod, University of Strathclyde
- 2. Books! Google isn't the only source of information Agenda • Why • A data-driven computer defence (Roger A Grimes) • Securing DevOps (Julien Vehent) • Social engineer (Iain Sutherland) 2 Books! Google isn't the only source of information
- 3. Why? 3 Books! Google isn't the only source of information I review books! Shameless Plug
- 4. A data-driven computer defence Roger A. Grimes • Author 10 books • Worked at McAfee • Worked at Microsoft • CPA, CISSP, CISA, CISM, CEH, MSCE, ETC, ETC 4 Books! Google isn't the only source of information
- 5. 5 A data-driven computer defence Books! Google isn't the only source of information
- 6. A data-driven computer defence “What are our top successful threats.”
- 7. A data-driven computer defence We need to: • Understand our organisation • Identify the question(s) to ask • Identify the data we need • Collect that data • Investigate (ask more questions and maybe identify more data to collect) • Analyse • Communicate the findings 7 Books! Google isn't the only source of information
- 8. A data-driven computer defence When I joined Strathclyde I did • None of that 8 Books! Google isn't the only source of information
- 9. A data-driven computer defence If you have no data, you can assume your biggest threat is from • Patch management • Social engineering 9 Books! Google isn't the only source of information
- 10. A data-driven computer defence Learn to ask the right question • Are we asking the right questions? • Do we have the right data to answer the question? • Be prepared to change both the questions and the answers as the situation requires 10 Books! Google isn't the only source of information
- 11. A data-driven computer defence What are our top successful threats? • "Everyone from the CEO to the food service employees should know the answer” 11 Books! Google isn't the only source of information
- 12. A data-driven computer defence Take Away's • Investigation and root cause analysis is so important • Ask the right questions • Gather the required data • Measure the correct indicators • Be prepared to change • Decisions based on data are defensible 12 Books! Google isn't the only source of information Buy this book!
- 13. Securing devOps Julien Vehent • Engineering Manager - Firefox Operations Security 13 Books! Google isn't the only source of information
- 14. Securing devOps The problem with Dev / Ops / Sec 14 Books! Google isn't the only source of information • "When the company's focus is directed outwards to its customers, security teams direct their focus inward" • "One wants to increase the value of the organisation, the other wants to protect its existing value" • "Each side is pressured to ignore the others and focus on its own achievements" • "I've never encountered dev or ops teams that didn’t care about security but I have met many frustrated with the interaction and goal disconnects”
- 15. Securing devOps Dev / Ops /Sec 15 Books! Google isn't the only source of information • Continuous integration • Continuous delivery • Continuous security
- 16. Securing devOps 16 Books! Google isn't the only source of information
- 17. Securing devOps Ops 17 Books! Google isn't the only source of information • Automated • Script based • Ensure each deployment is standard • Detect drift and reset
- 18. Securing devOps Dev 18 Books! Google isn't the only source of information • Develop small standalone snippets • Check in to a repository • Do some automated testing • Peer code review prior to release
- 19. Securing devOps Other great things about this book 19 Books! Google isn't the only source of information • Has code examples • Walks through the entire process with some open source tools • Suitable to give to your developers
- 20. Securing devOps Other great things about this book 20 Books! Google isn't the only source of information • Chapter 10 - a case study in incident response • Chapter 11 - risk management
- 21. Securing devOps Take away's • This book: - Gave me confidence to talk to the developers - Gave me the right angle to get developer buy in - Allowed me to find out they are doing some checks already - Allowed us to identify some security tests that could be implemented right now - Allowed us to write our "Development and DevOps Security Standards" 21 Books! Google isn't the only source of information
- 22. Social engineer Iain Sutherland • Fiction • Short story (86 pages) 22 Books! Google isn't the only source of information
- 23. Books! Google isn't the only source of information Books • A Data-Driven Computer Defence - Help you with your strategy • Securing DevOps - Help you with engaging with developers • Social Engineer - Awareness for senior management 23 Books! Google isn't the only source of information
- 24. Thank you customerservices@jisc.ac.uk jisc.ac.uk William Macleod University of Strathclyde
Notas do Editor
- Senior Cybersecurity Specialist I'm from an age before Google
- And what I've learned
- I got a website where I do 90 sec video review of books So I thought we not combine my hobby with me job. CLICK Also my book “Lilly and the sea fortress! Is available on Amazon. It’s a book to encourage 10-14year olds into thinking about a future in STEM subjects”
- This is the book that I wish I had 3 years ago Roger actually includes his email address in the book and I emailed him a question and to my surprise he replied, within 24 hours, so top marks to Roger
- This is how I often start a meeting – for years, in multiple companies But I’ve never thought about going and getting the data – I’ve just used it to shut down other people and to rail road my view through because I’m the expert or I’m the boss and my hunch is worth more Well this book is about going and getting that data and not relying on the hunch of experts
- I guess this is the key phrase that sums up the book. It’s all about getting “bang for your buck” and Roger sights many companies that spend millions on cyber defences but still get breached – why? Because the are spending in the wrong area because they do not know specifically what is happening in their organisation. This book sets out to help the reader understand what questions they should be asking and how they can go about gathering the data to answer those questions
- Only then should we be putting controls in place. Instinctively we know that is right, we should investigate and know the facts before making a move. IDENTIFY THE QUESTIONS TO ASK How do we know if an account is compromised What data do we need to workout how it was compromised FINDINGS 20% of breaches, to this organisation, originated from staff emailing documents to the wrong people 70% of breaches, to this organisation, origninated from staff falling for a phishing email (95% of those phishing emails reported to be a colleague sharing a OneDrive file) The most costly breach, to this organisation, originated from a webserver that was not patched correctly But it’s scary to do. Imagine coming into a new job and saying “yeah I’m not going to protect anything for 12 to 18 months – I’m going to spend that time trying to work out what is going on. “Dear Mr CEO – we shouldn’t go ahead and prevent the bad things, we need the bad things to happen so that we can learn how they are happening” – that sounds a bit perverse but when you think about it, it makes sense. A simple example though is lets say the company has had a spate of ransomware – so we go ahead and purchase new product to detect ransomware files in email but it’s been coming in via USB. Or we buy new endpoint antimalware software but ransomware is occurring on servers that don’t have a requirement for AV on them, due to historical performance issues. This book is full of similar real world examples from Rodgers work
- I was just popping and locking all over the place. We need security Here. Here and There. I even did some catalogue modelling "we need some security over there“ Just pointing out things that “every” company should have Identify Protect Detect Respond Recover I tended to think of Identify as Identify the Data and Asset to Protect Then Protect is before Detect, so you want to start Protecting things before Detecting things right? Really Identify should include Identifying what has happened and what is happening, which is arguably Detection. So we don’t just know what to Protect but what to Protect it from. I guess we need to remember the model is a circle, no particular start or end and each part reliant on the other. Detection for me was expensive SIEMs and Analytics and discovering APTs – but it can be really simple stuff like just asking people to fill in a few questions when account becomes compromised or malware is found
- Luckily. For me, Roger points out And the first things that I implemented where the likes of Vulnerability scanning / patch management / awareness training Phew! But even that isn’t simple without investigation and analysis. Lets say you have 99% of your estate patched to the latest level Everyone would pat themselves on the back, What a stat, what an effort. But what if our biggest successful historic breaches came on that 1% not patched? What if we find that 90% of our 99% is never attacked – so we’ve wasted a lot of effort and we are practically no more secure By asking the correct questions and gathering and analysing the data – being driven by the data – we will be doing a better job
- EXAMPLE from the book In the early years of last decade, Microsoft made its focus security – due to Bill Gates “Trustworth Computing” memo in 2002 It had a push to decrease critical security bugs in its code and created the Security Development Lifecycle It had huge success. This is a quote from the book “Some Major pieces of Microsoft software, like SQL server or DNS, have gone years without a single security bug. Even Microsoft’s Internet browsers have fewer bugs than their competitor. These statements usually shocks people, but it’s the truth and it’s a direct result of the SDL initiative” After success with their key metric, the realised that customers were still compromised the same amount. It wasn’t Micrsosofts code. It was 3rd party code and social engineering but that still had a negative effect on Microsoft as it was happening on their platform, in their ecosystem. So they now changed their question and KPI from “whether their software contained more or fewer security bugs” to “whether their customers were compromised to a greater or lesser extent over time and why” and invested in training the developer community in SDL.
- This is another interesting quote from the book. At Strathclyde we do awareness training – but we don’t spell out “these are our biggest issues” Seems counter intuitive Seems like a security issue to say “this is the easiest way into our company” But you can see why it’s important. If our biggest threats are from USBs then we want users to be more aware and cautious while using them. Or if the data that gets targeted the most is Engineer Research data, we want people to be more vigilant when using that type of data. It talks a bit about the culture of the organisation as well. Security is embedded throughout I haven’t gone this far yet but it is something I will discuss with the training and awareness team – but I at least have started highlighting our top risks to colleagues and putting regularly in reports as opposed to keeping it hidden away
- I have re-focused our team – not on protecting things but on investigating things. Discovering what happened and why Root cause analysis And that doesn’t have to be timely or costly – it can be a chat with the user – with 4 or 5 key questions - remember clicking on anything that gave you a strange feeling recently? Email? Webpage? - was it on your corporate device or a personal device? - had you just plugged in a USB stick? - did it happen on the network or somewhere else like hotel wi-fi? Also to ask questions and work out what data they need to answer those questions That is what is needed to feedback to successful adjust our strategy and give us bang for buck And ultimately Decisions based on data ARE defensible. I keep a well thumbed and marked copy of this book with me, as my cybersecurity bible. I highly recommend it
- So on to our second book This comes with an electronic download of the book also Now I started off my professional career as a developer – back in the days when testing consisted of "did it compile?" My career then went down the infrastructure route, where I spent about 15 years – so when it comes to my current security role I know exactly what needs done to secure infastrucutre. I knew I should have been doing something with the developers but words such as github, jira, jenkins, puppet, chef seemed to shroud modern development in mystic ways and I stayed away. This book gave me the skills and motivation to engage with the developers in the organisation. Whether or not your organisation works in a DevOps environment this book will help you talk to the developers – and I bet you if your organisation doesn't have DevOps, they are thinking about it and making sure security is thought about at this early stage is a win win.
- The first thing this book did for me was shine a light on what the issue actually is: Not just Dev and Ops vs Security – often Dev vs Ops – dev is about providing new functions – Ops is about providing stability "Interaction" “goal disconnects” or "Communication" is the problem – nothing technical
- The book then went on to explain to me how DevOps works and explains Continuous Integration – the process of quickly integrating new features into software Continuous Delivery – the automation of deploying software into services available And coins the phrase Continuous Security (in both the development and operational stages) We are already talking the same lexicon – so that helps with our communication issues
- Gave this diagram – sums up DevOps Even if not DevOps the Dev part will be getting done Mentioned ZAP – Zed Attack Proxy Baseline scan – can be done in minutes – perfect for a fast changing environment Armed with this info I could go and start a none frustrating conversation with the Dev and Ops teams (I wouldn’t call them DevOps yet)
- The Ops team where doing this or were moving towards this That’s a good goal from a security point of view – everything standard
- The dev team were doing this They were actually doing some testing already – just not necessarily security focused. So very easy for me to slip some tests into their process without massive overhead or change of procedures for them – in their instance they were using SonarCube – and we just added in the security testing
- How to spin up and deploy a sample application in AWS How to secure it's development and it's operation
- Chapter 10 – its really good. Scenrio is company conference in the Caribbean and someone sees some press coverage saying that all their medical devices are being recalled due to a failure. Transpires that this message is on the companies web pages. Unlike most incident table top exercises, which are high level, this is very techincal. Shows commands that an admin might use to check through logs and identify issues I think when it comes to incident response, a lot of focus is on the management of it – which is important, who is covering the press, who is putting out public messages, what they say etc Almost forget there is a lot of highly technical people running about doing their stuff. To me it’s highlighted that incident response thought exercises need to be used for techinical teams too Chapter 11 - So if you pass on to Devs or Ops teams – they will be learning some Risk Management also
- DevOps Security Standards I hasten to add this is high level, maybe more policy, and dev and ops teams are expected to write their procedure to comply but it’s a basic start It has highlevel statements like “The codification of infrastructure should be encouraged to ensure a consistent and efficient deployment of infrastructure” “Code must be stored in a secured central repository. ” “Code must be automatically security tested for common vulnerabilities, prior to check in to repository and recommendations acted upon.” “Security testing of code as early as possible and as often as possible should be encouraged.” If you have never tackled your developers, this book will give you the in
- Finally – and this is a quick one This is a prequal to Iain’s other book “Invasion of Privacy”, a large scale, technology based murder mystery (for a review visit www.macleod.guru) In this novel a young security consultant is hired to do a penetration test on a pharmaceutical company. The story introduces the techniques that social engineers have available to them and showcases how devious and devastating they can be. I think this is a good book to get into the hands of your senior management team. I gave a copy to our Principle last year. Its small enough and short enough that they can take it with them to read on a business trip and will confront them with some uneasy thoughts, forcing them to ask questions of your organisation – so be sure to have some answers up your sleeve.
- All books are available on Amazon although other booksellers do exist Any questions