This week, Michael talks about Facebook’s CSO Alex Stamos, Equifax, UpGuard’s new security tool, and Microsoft lifts update embargo on Windows 10. Jason Wood explains why you should build your own security tools in the expert commentary.
Facebook in the news
- When is a breach a breach (and when does it matter)?
- Consider the stock price hit – a sign of consumers paying attention?
- What is the role of security?
Former Equifax executive charged with insider trading after mega breach
- Concluded the breach and sold his stock… for nearly $1M, preventing $117k in losses
- Two weeks before the announcement, texted a co-worker, researched the 2015 Experian breach
- Other executives were cleared earlier
UpGuard’s new security tool automatically spots firms’ data leaks
- Organizations don’t know what they have, who has it, and where it exists
Microsoft lifts update embargo on Windows 10
- Removed the blockade on Windows 10
- But it’s in place for Windows 7
- “According to Microsoft, the security updates could brick PCs equipped with antivirus (AV) software that had improperly tapped into kernel memory.”
- Only the systems with compatible AV software, and a properly-set registry key, will receive those updates, however.
Why build your own security tools – I read a blog post by Harlan Carvey a couple of weeks ago that really made me think about how I viewed writing my own tools. In this post he laid out the reasons why he likes to write his own tools. Harlan gives two reasons for doing this. First, he likes getting the results of his script in the format that makes the most sense for him and his workflow. Second, he does it because he really get’s to know the data better that way. He has to interact with it directly, see the raw results and format things the way he wants. Along the way he may discover things in the data that he didn’t know was there. This second point is the one that really made me stop and think.
Typically, I don’t bother writing my on script or app if I can find something that does what I need. Most of this time this is because I am short on time and need to get the job done. For example, I may not have time to spend half a day working on a script if I am on a week long penetration test. Sometimes though, it is because I don’t want to take heat from my peers for doing something that may already have been done. One time I needed to get a password out of Outlook for a POP3 server. There are a number of ways that I could have handled this, but I decided to write a Python script that pretended to be a POP3 server and would print out the credentials. The script worked great and I decided to show off my shiny new script on Twitter. It didn’t take long for someone to point out that this was already a module in Metasploit. I was a little embarrassed, but for the most part thought it was pretty cool that it was there. But should I have been embarrassed? And should this be a reason to avoid writing and sharing a script? Harlan’s blog post gives some really good reasons why I shouldn’t have and why I should keep at it.
Here’s what I decided after thinking about Harlan’s post. One, who cares if someone has done it before? If I can learn what’s going on behind the scenes, then that makes me a better security pro. Sure, I can modify a script, but writing one causes me to learn a lot more. Plus I can stay much more in practice with my scripting and coding skills. Those skills are use it or lose it, so use it. This way when I run into a situation where I REALLY need to build my own tool, I’m ready to do so.
If you find yourself feeling the same way that I have about writing your own tools, take a look at Harlan’s blog post and think about it a bit. I think you’ll find that the personal benefits of developing your own tools (even if it may already exist) out weigh the negatives of writing something that may already exist. Obviously, this needs to be done with some judgment about deadlines and all, but it helps us avoid letting our skills regress and not knowing really what’s happening when we run a script or app.