De-Coder’s Ring

Consumable Security and Technology

Month: September 2017 (page 1 of 4)

Podcast: Interview with Wes Spencer

You can not miss this!  Wes Spencer is a seasoned CISO (Chief Information Security Officer) who’s currently working at Perch Security.  In this podcast, we talk about some tips and tricks for security organizations of all sizes.   Wes has some invaluable information for security technology buyers, so this is a must hear!

For more information on Wes, and to find items we refer to in the podcast,  please feel free to follow the links below.

Wes on Twitter

Rise and Fall of Silk Road (Youtube)

 

Connect with me to recommend a future interviewee or volunteer as one!

Subscribe here : https://fauie.com/feed/podcast

First Podcast is coming!

Man this has been a fun week.  The first podcast from the Decoder’s Ring (fauie.com) will be coming out early next week!

I’ll tell you now, the interview was fantastic and there is truly some invaluable lessons for any security product users and buyers.  My guest is fantastic!

Sign up for more info!

Technology: The first class citizen

I’ve spent the last few days at Capital One’s Software Engineering conference.   How cool is that?   Hundreds of techs folks gathering for a few days to discuss areas of technology.   These are modern stacks of technology, processes and new paradigms.

For me, I’ve been able to watch about a half dozen talks on Machine Learning, the programming language Go and encryption.  The speakers were excellent, and, if I play my cards right, I’m going to work to get a few of them on here as guest bloggers!

What topics would you want to hear about?

Security: Code and Passwords

Developer’s jobs aren’t easy.  Constant deadlines, integrating new technologies… dealing with ‘Ted’ in the cube next to you that shouldn’t be eating those onion rings… you get it..  lots of issues.  #notsnowflakes

stressed out developer

stressed out developer

Now we’re forced to live in this modern world of devops.  No longer can we rely on system administrators to maintain systems.  No longer can we rely on release engineers to package and ship our code.  Now we own it all.

Some of us adapt.  Don’t get me wrong, it’s not an easy task.  Most of us don’t have enough linux-foo, or the ingrained processes to maintain a large elasticsearch cluster… but we cope.  We learn new skills, grow in breadth of knowledge… then that breadth gets deeper.  Holy cow, we’re valuable now!

Unfortunately, security still is not a top tier concern for most software engineers.  We have web exploits to worry about.  We have to worry about SQL Injection.  Stack overflows, kernel panics, all kinds of neat stuff… each of which is the beginning of a piece of vulnerable software.

The one that continues to kill me, and I have this feeling was behind a major breach in the US this week, has to do with account and environment credentials.  There are so many scenarios that require an application to know about credentials:

  1. Database connectivity
  2. External API/Service
  3. Mail servers

tons more.  how do we deal with it?

There are a few anti-patterns

… bad things.. don’t do these.

  1. Hard code the credentials in your code
  2. Use a configuration file, check it into source control
  3. Use environment variables in your public facing website to connect to your super secret database

Those are all dumb.  Don’t do anything.

What can we do?

Separation of connectivity.   Your web application shouldn’t call your database directly, especially if it’s a database with customer data, personally identifiable information or healthcare info.  That’d be dumb.   Connect your web application to an API layer , but still follow some of the ‘other’ advice below.

Supply the passwords at runtime

Use a password vault/key management system to supply passwords to an application.  Build that out into your application framework so your code doesn’t have to be aware of where the password came from.   A password vault is a high security system that allows an authorized application to make a secure request to get private information from.  For instance, your vault could store the ‘production customer database’ information. This could even be information about the host name, port, username and password of the database.

Different environments get different credentials

This one is pretty obvious, but sometimes even the best of us don’t follow this to a T..   ummm…. no, not me.. others..  yeah.. others.   Just like your web sites, always have different passwords for everything.  Don’t reuse credentials in a QA environment and a production environment.

Provision as much as you can in configuration

Putting configuration items, or items that MAY become configurable in code is a bad move.  You’re gonna have a bad time.

You're going to have a bad time

You’re going to have a bad time

Always use configuration files. In the example above, the configuration file would tell your application where to find the password vault. Not the passwords or even the database configuration.

Act like your data is exploited

This point goes kind of against the other development tips.  When building applications, always remember that there’s a chance that the database ends up on the internet.   No one wants to think about it, but, look at Equifax.  Look at Deloitte.  Look at Aetna. Target.  etc.   They got owned, and you very well may too.   Don’t live in fear, but, live in paranoia!

 

Where’s my industry’s threat intel?

Over the past 18 months, I’ve had the pleasure of working on a platform that allows companies access to Threat Intelligence in a way they’ve never had before.  Instead of using a tool like Soltra Edge to just download intelligence, now, customers can use the Perch solution to also detect and triage any sort of alerts that come from their intelligence communities.  Intelligence communities appear in many different forms.  From the ‘informal’ e-mail or IRC channel groups that you’ll never know about, to the hyper formal ISACs (Information Sharing and Analysis Center) that are mandated by the US federal government.  I’ve written previously about community threat intelligence.

Cybersecurity: The Value of Community Threat Data

Tackling Expensive and Complicated Information Security

 

Yet I haven’t touched on a topic that plagues a lot of companies and industries.  

What if their industry doesn’t have a sharing center?

What if the companies don’t know about their industry sharing center?  

What if the company doesn’t know how to use the intel?

Worst of all, What if the community doesn’t have any intel!?!?!

To help work through some thoughts here, I wanted to invite my first ever guest write on my blog.  Curtis Davis.  I first met Curtis when he was investigating the Perch security solution.  Over time, we got to work together, including co-presenting a talk on Security Automation and Detection at the LegalSec2017 conference.   I found it fitting to continue our co-creation of thought provoking (hopefully) content around cybersecurity, with a topic related to this question.   

 

(logistics, Chris is on the left)

(Curtis is on the right, italics )

Where’s my industry’s threat intel?

Continue reading

Older posts

© 2017 De-Coder’s Ring

Theme by Anders NorenUp ↑