Saturday, September 29, 2018

Pushing Left, Like a Boss: Part 2 — Security Requirements

As previously published on my blog, SheHacksPurple.

In the previous article in this series we discussed why ensuring the security of software is an elusive task; application security is hard to achieve with how the InfoSec and software development industries and education system(s) currently works. We talked about the importance of starting security actives early in the SDLC and about formalizing them as part of your process. But what ARE these actives? How do they work, and when do we do what? That, dear reader, is what this article is about.
As you recall from the previous article, the system development life cycle generally looks like the image below:

System Development Life Cycle (SDLC)

Whether you are doing Agile, Waterfall, or if you have a DevOps culture at your office, you always need to know what you are building (requirements), you need a plan (design), you need to code it (the fun part), testing is obviously a must, and then you release it out into the wild (hopefully you also maintain and monitor it as well, which is all part of the “release” phase). Each one of these phases should involve security activities. Let’s look a little deeper, shall we?

Security Requirements

When writing requirements there will always be security questions, such as; does it contain sensitive or Personally Identifiable (PII) data? Where and how is the data being stored? Will this application be available to the public (Internet) or internally only (intranet)? Does this application perform sensitive or important tasks (such as transferring money, unlocking doors or delivering medicine)? Does this application perform any risky software activities (such as allowing users to upload files or other data)? What level of availability do you need? 99.999% up time? These and many more are the questions that security professionals should be asking when assisting with requirements gathering and analysis.
Here is a list of default security requirements that I would suggest for most software development projects:
  • Encrypt all data at rest (while in the database)
  • Encrypt all data in transit (on its way to and from the user, the database, an API, etc)
  • Trust no one: validate and sanitize all data, even from your own database
  • Encode (and escape if need be) all output
  • Scan all libraries and third-party components for vulnerable components before use, and regularly after use (new vulnerabilities and versions are released all the time). To do this you can use any one of the following tools: OWASP Dependency Check, Snyk, Black Duck, etc.
  • Use all appropriate security headers
  • Hash and salt all passwords. Make the salt at least 28 characters.
  • Only allow your site to be accessible via HTTPS. Redirect from HTTP to HTTPS.
  • Ensure you are using the latest version of TLS for encryption (currently 1.2)
  • Never hardcode anything. Ever.
  • Never put sensitive information in comments, ever. This includes connection strings.
  • Use all the security features within your framework, for instance session management features or input sanitization functions, never write your own.
  • Use only the latest version of your framework of choice, and keep it up to date
  • If performing a file upload, ensure you are following the advice from OWASP for this highly risky activity. This includes scanning all uploaded files with a scanner such as Assembly Line, available for free from the Communications Security Establishment of Canada (CSE).
  • Ensure all errors are logged (but not any sensitive information), and if any security errors happen, trigger an alert
  • All sanitization must be performed server-side, using a whitelist (not blacklist) approach
  • Security testing must be performed on your application before being publicly released
  • Threat modelling must be performed on this application
  • Code review (specifically of security functions) must be performed on this application
  • If the application errors it must catch all errors and fail safe or closed (never fail into an unknown state)
  • Specifics on role based authorization
  • Specifics on what authentication methods will be used. Will you use Active Directory? ASP.NET Core Identity? There are many options and it’s a good idea to ensure whatever you choose works with how you are manging identity for your enterprise and/or other apps
  • Only using parameterized queries
  • Forbid passing variables that are of any importance in the URL. For example, you can pass which language (“en”, “fr”, “sp”) but not your userid, bank account number or anything of any importance within your application if the value is changed.
  • Ensure your application enforces least privilege, especially in regards to accessing the database or APIs.
  • All users to cut and paste into the password field, but disable password autocomplete features
  • Disable caching on pages that contain sensitive information
  • Ensure passwords for your application’s users are long, but not necessarily complex. The longer the better, encourage use of passphrases. Do not make them change their passwords after a certain amount of time, unless a breach is suspected. Verify that new user’s passwords have not previously been in a breach by comparing sha1 hashes against the HaveIBeenPnwed API service.
  • All connection strings, certificates, passwords and secrets must be kept in Key Vault or something similar.
Depending upon what your application does, you may want to add more requirements, or remove some. The point of this article is to get you thinking about security while you are writing up your requirements. If developers know from the beginning that they need to adhere to the above requirements, you are already on your way to creating more secure software.
Up next in part 3 we will discuss secure design.

Friday, September 21, 2018

Pushing Left, Like a Boss: Part 1

As originally published in my blog, SheHacksPurple. - Tanya Janca

In all of the talks and articles I have ever written and all the advice I have ever given, I am always telling people they should “push left”. When security people say they want to "shift left", they are referring to the left side of the System Development Life Cycle (SDLC), which is the way software engineers describe the methodology or process for making software.
If you look at the image below, the further “left” you look, the earlier you are in the process. When we say we want to “push left”, we mean we want to start security at the very beginning and perform security in every step of the SDLC.
You might be reading this and thinking “Of course! Doesn’t everyone do that? It’s so obvious.” But from I’ve seen in industry, I have to tell you, it’s not obvious. And it’s definitely not what software developers are being taught in school.
As someone who was previously a web application penetration tester, I was generally asked to come in during either the testing phase, or after the product was already in production. At many places that I was hired I was also the very first person to look at the security of the application at all. When I was not the first person, often the person before me had been an auditor or compliance person, who had sent the developers a policy that was practically unreadable, generally unactionable, and often left the developers confused. As you can probably tell, I have not had productive experiences when interacting with compliance-focused security professionals.
Due to this situation, during engagements I looked AWESOME! I would always find a long list of things that were wrong. Not because I’m an incredibly talented hacker, but because no one else had looked. I seemed like a hero; swooping in at the last minute and saving the day. When in fact, coming in late meant the dev team didn’t have time to fix most of the problems I found, and that the ops team would have to scramble to try to patch servers or fix bad configs. They almost never had time to address all of the issues before the product went live, which means an insecure application went out on the internet.
As a security person, this is not a good experience. This is never the outcome I am hoping for. I want people releasing bulletproof apps.
You might be thinking: why are developers writing insecure code in the first place? Why can’t they just “make secure applications”? The answer is somewhat complicated, but bear with me.
One of the reasons is that most software development and engineering programs in university or college do not teach security at all. If they do, it’s often very short, and/or concentrates on enterprise security or network security, as opposed to the security of software (keeping in mind that they are learning how to make software, this should seem strange).  Could you imagine if someone studied to become an electrician, and they were taught to twist the wires together and then push them directly into the wall? Skipping the step of wrapping them in electrical tape (safeguard #1) and then twisting a barrette around it (safeguard #2)? This is what is happening in universities and colleges all over the world, every day. They teach developers to write “Hello world” to the screen, but skip teaching them how to ensure the software that they are creating is safe to use.
Another reason we are having issues securing software is that traditional security teams have focused on enterprise security (locking down admin rights, ensuring you don’t click on phishing emails and that you reset your password every X number of days) and network security (ensuring we have a firewall and that servers are patched and have secure settings). Most people who work on security teams have a networking or system administrator background, meaning many of them don’t know how to code, and don’t have experience performing the formalized process of developing software. The result of this is that most people on a traditional security team don’t have the background to make them a good application security professional. I’m not saying it’s impossible for them to learn to become an AppSec person, but it would be quite a bit of work. More importantly, this means we have security teams full of people who don’t know what advice to give to a developer who is trying to create a secure application. This often leaves developers with very few resources as they try to accomplish the very difficult task of creating perfectly safe software.
The last reason that I will present here is that application security is HARD. When you go to the hardware store and buy a 2x4 that is 8 feet long, it should be the exact same no matter where you buy it. If you get instructions of how to build a shed, you know that each thing you buy to build it will be standardized. That is not so with software. When building software developers can (and should) use a framework to help them write their code, but each framework is changing all the time, and upgrading regularly can be tricky. On top of that, most apps contain many libraries and other 3rd party components, and often they contain vulnerabilities that users are unaware of (but still responsible for). Add to this the fact that every custom software application they build is a custom snowflake, meaning they can’t just copy what someone else made…. And all the while attackers are attacking websites constantly on the internet, all day, every day. This makes creating software that is secure a very difficult task.
With this in mind, I’m writing a series of blogs on the topic of “Pushing Left, Like a Boss”, which will outline what different types of application security activities exist that you could implement in your workplace, and what types of activities that developers can start doing themselves, right now, to start creating more secure code.
In part 2 of this series we will discuss Security Requirements.

Thursday, September 20, 2018

September Connector

*|MC:SUBJECT|*
OWASP
Connector
September 2018

COMMUNICATIONS


Letter from the Chairman
Dear OWASP Community,
We are only one month away from AppSec USA. OWASP is dedicated to education and bringing the community together. We really do hope you are able to come to AppSec USA to participate in a great conference. It's going to be a conference filled with more than 15 hands-on training courses and over 120 hours of talks with strong Keynotes by:
Chenxi Wang, Michael Coates, and  Armon Dadgar.

Looking ahead we are working on strengthening the foundation with a focus on our foundational priorities: projects, education, and community.   In the next months, we will continue to focus more support of the regional events, chapters and projects trying to develop a stronger community with increased engagement with the community working together to guide the foundation and help it reach its objectives.   The new Executive Director, Karen Staley has contacted many of you and will continue to do so to reach out and learn and ask for your support as she works to strengthen the community and OWASP.    Please support her in this endeavor as she tries to find the best way forward with your guidance and input.

I hope you enjoy this months connector with information on community, projects and the regional events.   I look forward to seeing you in San Jose!
 
Your Chairman,
Martin Knobloch
OWASP Chairman of the Board of Directors
We are happy to announce the verified candidates that will be in the election for the Global Board of Directors for the OWASP Foundation.

Bill Corry
Richard Greenberg
Kishore Kumar
Martin Knobloch
Ofer Maor
Gary Robinson
Simon Whittaker
OWASP Foundation Staff Announcement:
Laura Grau has moved on to another opportunity.  We at the Foundation thank her for her 5 years of service.  We wish her all the best in her new endeavor and hope to fill the position at a later date.

PROJECTS

 
Projects were busy this past month:
**Check out OWASP Wiki Page for the New and up to date Flagship Project List.**
More changes to come!

EVENTS 

 
Will you be there?

AppSec US 2018 in San Jose, CA
Register now before time runs out.
Check out the schedule of training.
The Fairmont 

OWASP has a room block for AppSec US 2018 attendees to book a room at the conference hotel.  Call the Fairmont at (408) 998-1900, mention OWASP and AppSec USA.

 

You may also be interested in one of our other affiliated events:
REGIONAL AND LOCAL EVENTS
Event Date Location
AppSec Israel September 5-6 Tel Aviv, Israel
OWASP Tampa Day September 21 Tampa, FL
OWASP Portland 2018 Training Day October 3 Portland, OR
OWASP Poland Day 2018 October 10 Poland
OWASP AppSec Day 2018 October 19 Melbourne, Australia
OWASP Cagliari Day 2018 October 19 Cagliari, Italy
LASCON 2018 October 23-26 Austin, TX
OWASP AppSec Bucharest 2018 October 25-26 Bucharest, Romania
OWASP BASC 2018 October 27 Boston, MA
OWASP AppSec Indonesia 2018 November 1-3 Indonesia
AppSec Morocco 2018 November 15-16 Morocco
German OWASP Day November 19-20 Münster, Germany
OWASP Norway Day 2018 November 29 Norway
AppSec California 2019 January 22-25, 2019 Santa Monica, CA
Mansoura Chapter and Besides Cairo Security Day February 1-2, 2019 Cairo, Egypt
Snow FROC 2019 March 14, 2019 Cable Center Denver, CO

PARTNER AND PROMOTIONAL EVENTS
Event Date Location
(ISC)² EMEA Secure Webinars June 26, 2018 - Weekly Virtual
44CON September 12-14 London
Cyber Range Academy 2018 October 7-8 Malasya
Cyber Resilience Summit October 16 Arlington, VA
DevSecCon London October 18-19 London
HITB SECCONF 2018 Beijing October 29-November 2 Beijing
Infosecurity North America New York November 14-15 New York
QuBit Conference Sofia November 16 Sofia, Bulgaria
HITB SECCONF 2018 Dubai November 25-27 Dubai
QuBit Conference Belgrade November 30 Belgrade, Serbia
UPDATE: We anticipate getting the videos from AppSec EU posted mid-September.  Subscribe to our YouTube channel to get an update when they are posted.

Community

Chapter and Project Leaders
2 Town Hall Meeting - GoToMeeting

September 21, 9:00 AM (US Eastern) -  GoToMeeting Link or +1 (646) 749-3122 + Access Code: 520-699-309

September 28, 3:30 PM (US Eastern) - GoToMeeting Link or +1 (872) 240-3212 + Access Code: 755-635-893

(Convert these to your time zone)

 

MEMBERSHIP

Contributor Corporate Members

join us
make a donation
Our mailing address is:
OWASP Foundation
1200-C Agora Drive, # 232
Bel Air, MD 21014
Fax: 1-443-283-4021
Contact Us  
Unsubscribe






This email was sent to *|EMAIL|*
why did I get this?    unsubscribe from this list    update subscription preferences
*|LIST:ADDRESSLINE|*