Tag Archives: awareness

OWASP 2017 Changes

When I talk to people about application security, the most recognized topics is the OWASP Top 10. If you haven’t heard of the top 10, or need a refresher, you can get the full list at:

https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf

The OWASP Top 10 is on a three year update cycle. We had the list in 2010, 2013 and now the latest is 2017. You may be wondering why it is 2017 rather than 2016. I think that is a question a lot of people had. In any case, the list made it out to final release after the initial draft was rejected. Now that it is here, we can analyze it and see how it affects us and our organizations.

https://www.youtube.com/watch?v=kfDuxwFScOE

What I think sticks out more to me this update over previous updates is the removal of some pretty common flaws based on my experience. In the past we have seen flaws move up or down on the risk level, or get combined, but not as much removed. In 2017, we saw two items get removed:

Cross-site Request Forgery
Unvalidated Redirects and Forwards

I find these items interesting because I see them on most of the assessments I do. Let’s take a quick look at them.

Cross-site Request Forgery

CSRF can be a pretty serious flaw based on its context. It is the ability to force the victim’s browser to make requests to another site they are authenticated too without their knowledge. An example of a higher-risk context is the ability to change the victim’s email address on their profile. If the system doesn’t have two factor authentication or other safe guards, changing the email address can lead to the ability to request a password reset. In many situations, this can lead to easily taking over the victim’s account.
This is just one example of how CSRF can be used. The good news is that many newer frameworks provide some level of CSRF protection built-in. So in many applications it is not as prevalent. However, based on my experience, not everyone is using the latest frameworks. Due to this, I still find this on a lot of the assessments I do.

Unvalidated Redirects and Forwards

Unvalidated Redirects is often viewed as a low risk issue. In many cases, it may represent a low risk. There are some situations that make unvalidated redirects fairly dangerous. A good example is the redirect often performed by login forms. A common feature of many applications is to redirect the user to a specific resource after logging in. To do this, a parameter in the URL specifies the path to be sent to. If the application allows redirecting to external sites, it is simple to set up a malicious site with the same look and feel as the expected site. If the victim uses your link with the reference to your malicious site they may be presented with your fake login page after successfully logging into the real site. The victim may believe they have mistyped their password and just login again without checking the URL, leading to account takeover.

We also saw to access control findings get merged into one. This change makes a lot of sense when you look at each item. They are both regarding access control issues.

With the removal and merging, the list has brought on three new vulnerabilities:

XML External Entities (XXE)
Insecure Deserialization
Insufficient Logging and Monitoring

XML External Entities (XXE)

XML External Entities is a vulnerability that takes advantage of how XML Parsers interpret the supplied XML. In this case, it is possible to reference other resources outside of the XML document. A common scenario is the ability to read other files on the web server, such as the /etc/passwd file. This vulnerability also may allow a denial of service attack to occur due to embedding specific entities. This vulnerability obviously relies on the application parsing XML data. If your application is parsing XML, it is recommended to make sure the parser is ignoring or blocking DTDs. If your parser doesn’t have that option, or you need to allow some DTDs, make sure your input validation is limiting those to only acceptable ones.

Insecure Deserialization

Insecure Deserialization occurs when you are deserializing data that has not been properly sanitized. This occurs because we assume that the data serialized has not been modified. When the data is modified, it could be executed during the deserialization process to perform commands. To help prevent this, make sure you are enforcing strict data checks on the objects that have been serialized. I do not see this very often in many of the assessments I do. Just depends on the application as many do not use much serialization.

Insufficient Logging and Monitoring

When I talk to people and ask them about logging, the first response, or usually the only response, is related to troubleshooting. There is no doubt that troubleshooting is critical for any application. If the application is not running as expected, users may leave, transactions may get lost, or a myriad of other issues may occur. Logging is for much more than just troubleshooting. Proper logging of security related events can help identify an attack while it is occurring as well as help identify what happened after the fact. It can be very difficult to identify what data was accessed or how if there are no logs indicating such information. It is good that we are seeing more attention called to this practice, although it can be a complex one to implement and verify. Don’t forget that once you start logging security events, they must be monitored to take action.

Wrap Up

Changes to the OWASP Top 10 isn’t something new. We know it will happen and it may require some adjustment to what we are doing internally. While we do see items drop or get added, it just highlights that the top 10 is a mere starting point of security. Every organization should have their list of top 10 risks. Don’t limit yourself to these short lists. They are to help identify the highest risks and implement them in a feasible way. Application security doesn’t happen overnight. There has to be a starting point and then a path to mature.

Listen to the podcast on this topic. http://podcast.developsec.com/developsec-podcast-91-owasp-top-10-2017-thoughts

Two-Factor Authentication Considerations

Leave a reply

There was a recent article talking about how a very small percentage of google users actually use 2-factor authentication. You can read the full article at http://www.theregister.co.uk/2018/01/17/no_one_uses_two_factor_authentication/

Why 2-Factor

Two-factor authentication, or multi-factor authentication, is a valuable step in the process to protect accounts from unauthorized users. Traditionally, we have relied just on a username/password combination. That process had its own weaknesses that many applications have moved to improve. For example, many sites now require “complex” passwords. Of course, complex is up for debate. But we have seen the minimum password length go up and limitations on using known weak passwords go up. Each year we see lists of the most common passwords to not use, some being 123456 or Password. I hope no one is using these types of passwords. To be honest, I don’t know of any sites I use that would allow this type of password. So many these days require a mix of characters or special characters.

https://www.youtube.com/watch?v=YxXebkpSLr8

The above controls are meant to help reduce the risk of someone just guessing your password, there are other controls to help try to limit brute forcing techniques. Many accounts offer account lockout after X number of invalid attempts. There are other controls that we also see implemented around protecting the username/password logic. None of these controls help protect against a user reusing passwords on another site that may be compromised. They also do not protect against a user falling for a social engineering attack to trick them into sharing their passwords. To help combat this, many sites will implement a second factor beyond username/password.

The idea of the second factor is that even if you have the username and password, you will not have this other piece of information. In most cases, it is a value that changes every 60 seconds or so, and is delivered over a protected channel. For example, the token used may be sent via SMS, a voice call, or created through a phone application like the Google Authenticator application. So even if the attacker is able to get your password, via a breach, brute force, or just lucky guessing, in theory they would not have access to that second factor.

Why Are People Not Using It?

So why do people not enable the second factor on their Google accounts? Unfortunately, the presentation didn’t appear to explain that, which makes sense since it is difficult to know why people do or do not do certain things. I think there may be a few reasons for it that we will briefly touch on.

First, I think many people just are not aware of enabling the second factor. To be fair, it is sort of buried down in settings that may be difficult to find if you are not really looking for it. If it is not front and center, then there is a much smaller chance people will go seeking it out. To add to the issue, many people really don’t understand what 2-factor authentication means or how it really helps them. Sure, in security we get it, but that doesn’t mean everyone else does. How do we make it more prominent that this is a positive security feature? Many users will already be aware of 2-factor if they use online banking as most of those have started enforcing it.

Many people think that two factor authentication is a burden or it will slow their access down. This is usually not the case unless the application has implemented it poorly. Many sites will allow you to save your computer so you don’t need to enter the 2nd factor every time you access the site. However, it will require it if you access from a different computer.

To complicate things, other applications may not support signing in with 2 factors, like your email client. In these cases, you have to generate an app password which can be very confusing to many users, especially those that are not technically savvy.

There may be a chance that users don’t think they need to protect their email accounts, that it is not sensitive. If you just use email to communicate with friends and receive junk mail, what could be so bad, right? Most people forget that things like password resets are performed using an email account. Having control of an email account provides a lot of control over a lot of things. While it may seem small, email is an important function to protect.

If you are using Gmail, I recommend configuring 2-factor authentication. The following video walks through setting it up using SMS (Although there are other options as well):

Demo- Google 2 factor

If you are developing applications, I recommend looking into providing the option of 2-factor authentication. When you do this, make sure that you are promoting its use in a positive way. If you already have 2-factor with your application, can you run a report to determine what percentage of users are actually using it? If that number is low, what steps can you take to increase them?

Don’t assume that any application is not worthy of the extra security. Many applications are already providing 2-factor and that number will just increase. While we still have the password, we will always be looking for ways to add more protection. When implemented properly, it is simple for the end user, but effective in increasing security. If your user base is not taking advantage of the option, take the time to assess why that is and how it can be improved.

As I was writing this up, I ran into an interesting situation with 2-factor that sparked some more thoughts. When looking to support 2-factor authentication and not using SMS, take careful consideration to the applications you may choose to support. On the Apple App Store alone there are over 200 different authenticator apps available. Some are interchangeable while others are not. This can be another barrier in users choosing to enable 2-factor authentication.

Tinder Mobile Take-Aways

Leave a reply

While browsing through the news I noticed an article talking about the Tinder mobile app and a privacy concern. You can read the article at https://www.consumerreports.org/privacy/tinder-app-security-flaws-put-users-privacy-at-risk/. To summarize what is considered the issue is that the mobile application does not transmit the photos that you see using HTTPS. This means that anyone on the same connection can see the traffic and, ultimately, see the photos you are presented. From my understanding, it doesn’t appear the potential attacker can tell who the user is that is viewing these photos as the rest of the traffic is properly using HTTPS.

We have discussed the move to all HTTPS multiple times on this blog and we are seeing a lot of sites making the switch. With web applications it is easy to see if the site is using HTTPS or not with the indicators near the address bar. Of course, these indicators are often confusing to most, but at least we have the ability to see the status. With a mobile application it is much more difficult to tell if data is transmitted using HTTPS or not because there is no visible indicator. Instead, one needs to view the raw traffic or use a web proxy to see how the data is transmitted. This can be misleading to many people because the assumption is that the data is protected because it is hidden under more layers.

In this instance, the ability to see these photos may not be considered that sensitive by many. Assuming that anyone can create an account and see the photos doesn’t make them a secret. People have opted to post their images for others to find them on the network. Of course, level of sensitivity is in the eye of the beholder these days. Another issue that is potentially possible in this situation is that the attacker could manipulate that image traffic to show a different image. This could lead to the end user seeing a different image than the one expected. The usefulness of this could be called into question at any type of large scale.

The take-away here is that when we are building applications we must take care in understanding how we are transmitting all of our data to determine what needs to be protected. As I mentioned, there is already a push to make everything HTTPS all the time. If you have decided not to use HTTPS for your connections, have you documented the reasons? What does your threat model tell you about the risks with that data and its communication. How does that risk line up with your acceptance procedures.

Another interesting tidbit came out of the article mentioned above. In addition to seeing the actual photos, they found it was possible to identify whether or not the end user liked or disliked the photo by comparing the network traffic. The interesting part about this part is that those decisions were encrypted when transmitted. The key point here is that the traffic for each decision was a set size and the sizes were different for like and dislike. By viewing the traffic after seeing a photo, it is possible to determine which ones were liked based on the size of the requests. In this case, it still doesn’t identify the end user that is using the application.

We don’t typically spend a lot of time analyzing the size of the requests we send in the event someone may try to determine what actions we are taking over an encrypted channel. Most of the time these actions are not possible to determine, or the level of effort is way above what is realistic. The easy solution would be to make sure all traffic was encrypted and we wouldn’t be able to know what images were liked or disliked. Maybe it would be possible to still see the difference, but with no way to tie it to specific images. The other option is to attempt to pad the requests so that they are all the same size. This would be for highly sensitive systems as the complexity may not be worth the benefit.

Of course, all of this is based on the attacker being on the same network as the end user so they can intercept or view the traffic in the first place. In the case of a public place, it might just be easier to hover over your shoulder and watch you use the app then intercept the traffic and guess at who is using it.

Both of these topics are good conversation starters within your organization. They help us realize that even just one request that doesn’t use HTTPS may be seen and could raise an issue. It also helps us to see that sometimes even encrypted data can be determined, but that doesn’t mean it is a high risk. Each situation is different and should be properly analyzed to determine the risk it creates for the company and the organization.

Remember Me Features

Leave a reply

Tired of constantly logging into your applications? Don’t you wish they would just remember you each time you visit, logging you right in? It isn’t as always easy to achieve such a status. There are multiple ways remember me can be implemented. Lets take a look at some of them.

Remember UserName

One of the most common ways for a site to implement the remember me functionality is to remember the username only. The username is typically stored in a cookie on the client’s computer. Remembering the username helps speed up the authentication process, but doesn’t eliminate it. The user still has to enter their password to gain access to the application. Although this is a common technique, some organizations may have data classification policies that don’t allow displaying the username in the application. This can also carry over to the username and the login screen. For these organizations, they may not implement a remember me feature at all. Remembering the username does contain some risk, as it instantly provides the username to an attacker on the user’s computer. This leaves just the password for the attacker to determine, which may be feasible if the user re-uses passwords that have been previously breached.

Long-term Auth Cookies

Another common technique for remembering a user is to set an authentication cookie that has a long life. Once you login, a cookie is created that may not expire for a year or longer. This allows you to be automatically logged in each time you visit the site. I am sure you can think of a few sites that provide this functionality. It is common among some of the social media sites people visit all the time. This is not recommended for any type of sensitive applications because it would allow immediate access to anyone that gains access to the user’s device.

Storing Password Locally (Remember Password)

Another option, that probably shouldn’t be an option, is storing the password on the user’s computer. This was recently seen on a web application, however we won’t mention the site that did this. We can, however learn from their decisions. In the application, they used CryptoJS to encrypt and decrypt this type of sensitive data. In this case, they stored the password in a cookie. With the encryption routines available on the client, it is possible to use them to decrypt the encrypted password with very little effort. This is typically the case any time the routines are made available, especially if the keys are available as well. While I am sure this was done with good intentions, the implementation is not very secure. As a matter of fact, it provides more of a false sense of security. This is most likely due to the use of encryption. It is not recommended to perform this type of encryption client-side, nor is it recommended to store the user’s password on the client like this.

What Next?

There are multiple options to help ease the burden of frequently logging into an application. Depending on the type of application, data stored, and sensitivity of the transactions, the options should be considered carefully. Providing the option to remember a username is convenient with some residual risk. Keeping a user logged in for extended periods of time increase the risk, but may be acceptable depending on the application and its use. Stay away from storing the user’s password locally on the computer they are using. Secure implementation is not easy or straightforward, increasing the risk levels.

Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you. James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

When One Testing Solution Isn’t Enough

Leave a reply

Go to any conference, attend some webinars, or just do a search for application security testing solutions and you can quickly see the sheer number of solutions out there. As in every situation, there are some that are great and some that are not so great. With such great marketing, it is often very difficult to determine what is the best solution. All too often people are looking for that silver bullet. That one testing tool or pen testing company that will find everything. Unfortunately, that solution doesn’t exist, or I just haven’t seen it.

Application testing usually falls into two categories: Automated scanning and manual assessments. To break that down further, automated scanning is broken down into two disciplines: Static and dynamic.

Static Analysis

Static scanning means that code is scanned without running it. Here is a quick post about static analyzers. Inputs are traced through the code to see what paths are taken and determine vulnerabilities. Static scans can be efficient at finding flaws such as cross-site scripting, injection flaws, configuration issues, etc. Static scans excel at finding code issues like hard coded passwords, cryptography issues, and other items not possible through a dynamic or manual test. They still do not do very well at finding business logic flaws which can be the most devastating.

Dynamic Analysis

Dynamic scanning means that the application is scanned as it is running. Unlike a static scan, it can be very difficult to identify hard coded passwords or cryptographic issues because they are not visible to the end user. Dynamic scans do a decent job of identifying other flaws such as cross-site scripting, injection flaws, insecure cookies, and some other configuration issues to name a few. Dynamic scanners do not do a good job identifying authentication, authorization, or business logic flaws in general. Properly tuned scanners may be able to do this, but that requires extra work.

Manual Assessments

Manual assessments are mostly a manual process of analyzing source code or using the application to find security flaws. Source code review, has many advantages of the static scanning mentioned above. Penetration testing is very similar to the dynamic scanning mentioned. In both cases, the testing is done manually vs. using just an automated tool. Manual assessments (pen tests) are much more efficient at finding authentication, authorization and business logic flaw types. Of course the quality of the assessment is heavily influenced by the skill of the person doing the assessment.

Some of the big vendors have started offering all three types of assessment for their customers. The big players (White Hat Security, VeraCode, HP, etc.) all offer static, dynamic and manual assessments for your applications. And with good reason. If you have worked in an enterprise where you are required to have multiple assessments by different groups you quickly realize how nothing provides a complete solution. Each assessment paints a portion of the security picture. Items found by one may not be found by the other. In some instances you may think that two should have found the same item, but that is the nature of security.. No one finds everything.

Multiple Solutions

While you may think that it is overkill to have multiple scanning solutions or testers looking at an application, they all bring a different viewpoint and help identify different types of vulnerabilities. Sort of like an enhanced second pair of eyes. Not only can they double check the work the other has done, but in may situations they can identify different types of vulnerabilities. Not only do different solutions find different vulnerabilities, they also find them at different phases of the development lifecycle. It is common to use the static scanners in the development phase. Dynamic scanners are more commonly seen in the verification phase. Manual assessments, especially 3rd party penetration testers, are also in the verification phase, but near the end of the cycle. The closer to development a flaw is found, the quicker it is to remediate it.

The right solution is the one that fits your environment. Take the time to analyze your setup to determine the best way to implement a solution. These solutions take time and should be carefully considered.

The FTC’s “Start with Security: A Guide for Business” Document

Leave a reply

The FTC recently released a document to help companies learn from others’ security mistakes. The document titled Start with Security: A Guide for Business. It provides ten (10) different security lessons learned by other companies, included below:

Start with security.
Control access to data sensibly.
Require secure passwords and authentication.
Store sensitive personal information securely and protect it during transmission.
Segment your network and monitor who’s trying to get in and out.
Secure remote access to your network.
Apply sound security practices when developing new products.
Make sure your service providers implement reasonable security measures.
Put procedures in place to keep your security current and address vulnerabilities that may arise.
Secure paper, physical media and devices.

The thing I find unique about this document is that it is not technical, actually quite the opposite. It is a high-level description of the security lesson. Additionally, it identifies businesses that have had cases brought against them.

It is great to see a new approach to identifying why security is important. Using lessons from other companies shows a direct relation to the security lesson. It is no longer a matter of theory, these things do have consequences.

I have recorded a 20 minute podcast providing an overview of the document. I will also be breaking down a few of the topics to cover them in a little more detail. I recommend taking a moment to take a look at the document the FTC has provided. It is a quick read.

Tips for Protecting Credit Card Information

Leave a reply

Turn on the news and you will see a breach announced for some company. It is happening all the time. In most cases we, as consumers, accept the risk for the convenience of using a credit card for purchases. While there isn’t much you can do to protect your information once you have given it to a business, there are some things you can do to help reduce your risk while shopping online.

Scan for Malware

Most of our online purchases happen from our own computer indicating that this is where we should start our own protections. Over the years we have always told people to make sure you are running anti-virus software, but there are other types of malicious software (called malware) that these programs often don’t detect. Malware is software that is installed on your computer, usually without your knowledge, that has a malicious intent. It may be that it is trying to steal your passwords, credit card information, or other sensitive information. It might be software to spy on you using your computer’s built in microphone or video camera. In any case, it is software that you do not want installed.

There are other programs that you can get to remove this type of malware, above and beyond the use of anti-virus software. A program that I found very useful, that I don’t have any affiliation with, is MalwareBytes (https://www.malwarebytes.org). The greatest benefit is how easy the program is to use (oh and they have a free version). It scans your system for malware and does a really good job of removing it for you. If you have ever tried to remove malware before, it can be pretty difficult. Not with some of these programs like MalwareBytes. If you notice your computer running slow or acting odd it may be a good idea to give it a scan to see if anything comes up.

Be Careful with Emailed Links

Phishing, the art of sending emails with the intent on tricking the user into visiting a malicious site or installing malicious software, is a common way for an attacker to infect your system. All too often we have been told to not open attachments included in an email from someone we don’t know, but this is also true for clicking on links. In many cases, those links do not go to where you are expecting them too. Lets look at a quick example. I have created a simple fake email with some made up business and web site addresses.

BadEmail1

The link in the image above looks normal, however when we take a moment to inspect it more it turns out not to be. To inspect the link, most email clients allow us to hover over it for a moment to see a preview. Hovering means to place your mouse over the link, but don’t click the button. After a few seconds, a balloon should appear to show you what the link actually points to. The following image shows this in action.

BadEmail2

If it is possible, it is recommended to type out the link that is presented or go to the site directly in the browser (if it is a familiar site) rather than clicking on the link. It is understandable that this is not always possible, as some links contain a special discount code or special offer. In these cases, take the time to make sure that the link is going to the site you are expecting. As with any security tip, trust your gut. If something doesn’t seem right, don’t enter any type of personal information with it.

Verify the Site is Using HTTPS

When you are about to use your credit card online, make sure that the web site you are using is using HTTPS. HTTPS means that the information you provide will be encrypted, or protected, as it is sent to the web site. Think of it like using a security envelope vs a regular envelope when sending snail mail. Of course, there are other protections that make it more secure than a security envelope, but that should be a good analogy for most people. There are a few ways to verify this. First, you can look at the address bar in the browser that displays the site name and make sure it starts with “HTTPS”. The next step is to verify that there is a padlock icon near that site address. The image below shows this site and in the top left you will see the padlock icon and https://www.developsec.com. That indicates that the site is using HTTPS and your data will be protected when sent to the business.

DevSec1

You can also verify even further, by clicking on the padlock (in FireFox) the site name matches up with the certificate name. In the below image you will see that the box that appears states I am connected to developsec.com.

devsec2

When Searching, Select the Right Site

If you are using Google or Yahoo, or some other favorite search engine, make sure that the search result you click on is the site you are expecting. With how technology is advancing and the way we have updated how search engines work, there are possibly thousands of results that may come back. Search engines also often put ads as the first few results. Take a moment and ensure that you are going where you think you are going. Don’t just click the first link that is returned.

The following image shows a search for FireFox for Mac. Notice how there is an Ad (which does point to the real FireFox download) and then multiple results. The ones that go to Mozilla.org are valid results that go to the creators of FireFox. Under that are results that don’t go to Mozilla.org. While these sites may be valid downloads of FireFox (I did not try them), you want to try and stay with the creators or the software if possible. Often times software is repackaged by other vendors and that repackaging adds in software you may not want.

Trust Your Gut

Security often times comes down to trusting what your gut tells you. If something seems out of place, then it probably is. If you don’t feel comfortable, then don’t input your sensitive information. Researching the item more can also help make a decision. if you are downloading software, do other searches about it to see if people downloaded malicious versions. If it is from a different site than the vendor, do a search to see if anyone else has flagged that download as bad. Finally, if you notice fraudulent charges, make sure you notify your credit card company as soon as possible.

Best Practices for Cyber Incident: DoJ Released Guide

Leave a reply

Breaches and other security incidents are happening all of the time, and can happen to anyone. Do you know what to do if an incident occurs in your backyard? The Department of Justice recently released the Best Practices for Victim Response and Reporting of Cyber Incidents to help you understand the process. Looking through the 15 page document, there are quite a few great points that are made. Here are just a few examples of what are included. I encourage you to check out the entire document as this won’t do it justice. It covers 4 topics:

Before the Incident
Responding to the Intrusion
What Not to do Following an Incident
After an Incident

The document is broken down into different topics, starting with before the intrusion actually occurs. This step is often overlooked because we never think it will happen to us. Talk to anyone that performs incident response or forensics and while these tasks are performed after an incident, what was done before the incident can be a game changer. Don’t forget baselines of your systems to know what is normal.

It is good practice to identify what is important to your business, that is, what you need to protect. This is different for every company. The next step is to create an action and response plan in the event an incident occurs. Well thought out plans make dealing with an incident easier. Make sure you are including non-technical resources in this planning. This may include the legal teams, human resources, public relations, and a wide array of other personnel within the company. When a breach occurs, there are a lot of moving parts to deal with.

Forming a relationship with law enforcement is also a good idea. It makes it easier to contact them in the event of an incident and you may feel more comfortable with the situation. The relationship may also lead to information ahead of time that could be useful to thwart an impending attack.

Once an incident occurs it is time to respond to it. This is the 2nd topic covered by the report. This starts with making an initial assessment of the situation. Who is logged on, what systems are affected, etc. Once you have identified affected systems it is time to implement measures to minimize damage. This might include removing systems from the network, shutting them down or segregating them. Once protected it is time to collect information about the incident, often requiring imaging of the affected systems. Note: If you are not sure how to do this it is a good idea to contact a professional. You do not want to risk damaging the evidence.

Once you have identified the affected systems/data it is type to put the notify portion of your action plan into effect. Don’t forget that it is more than just notifying customers. You want to understand which customers need to be notified, but also vendors/partners and internal employees. Depending on the situation, law enforcement may also need to be notified.

I really like that the document contains information about what NOT to do following an incident. Professionals that don’t focus in IR and Forensics tend to not think about what they shouldn’t be doing that could cause problems with the investigation or themselves. The affected systems should not be used for any communication unless absolutely necessary. These systems are most likely compromised and you can’t expect any information to be safe at this point.

While hacking back seems to be a debated topic these days, the recommendation is to avoid it. While the laws are broad when it comes to CFAA and other computer crimes, you don’t want to go from victim to defendant. Let the authorities deal with the issue.

Finally, once the incident is cleared and complete, stay vigilant. Don’t assume that once you get attacked it won’t happen again. Learn from what happened to help reduce the chances it will happen again.

My summary above just touches on the tip of the information provided in the document linked above. It is nice to see we have a list of best practices that are not technical that many should be able to understand. Even if you are not part of incident response or dealing directly with cyber incidents, take a moment to read the information as it might be helpful one day.

Is HTTP being left behind for HTTPS?

A few years ago, a FireFox plugin was created called FireSheep. This tool was designed to sniff network traffic looking for common websites that were being visited over HTTP. HTTP sends the traffic between your system and the server in clear text. If it found a request/response of an authenticated user, it would capture the session cookie and allow the user of FireSheep to hijack the current session. While the site most likely performed the initial authentication with the username and password over an encrypted channel, such as HTTPS, it then degraded to HTTP for the rest of the site visits. The premise was that the credentials were protected, but the flaw in that approach is that the session cookie used to represent an authenticated user also needs to be protected. In this case, it was not.

It is starting to become more popular for sites to allow support for HTTPS (the encrypted transport channel) all of the time. Many sites like Facebook, Google, LinkedIn, Twitter, etc. started making this available as an option after the release of FireSheep. If your site uses any type of authentication, it is recommended to only use an encrypted channel (HTTPS) for communication.

What if your site doesn’t use authentication? What if it is just your company’s marketing website? What if your site just provides information to people but there are no passwords, sensitive information, or sessions to protect? Should you still switch to HTTPS?

This is a debate that is starting to grow in the information security world. With concerns of government snooping, or other entities snooping on traffic, many suggest dropping HTTP and only supporting HTTPS. There is also the concern that your site, if using HTTP, could allow an attacker to intercept and modify your responses to directly attack your system. While not attacks, we have seen ISPs deliver ads or other content by inserting it into the responses. If an attacker can do this, it is possible for an attack payload to be sent and your system comprimised. If you are on a corporate network this is the first step at attacking the internal network from teh outside.

On the flip side, we don’t see these types of attacks very widespread and many people are not worried about any type of snooping. They just want to get their information. So does it make sense to just go ahead and drop HTTP and go for the gusto? Pintrest just joined the ranks of going to all HTTPS (https://threatpost.com/https-opens-door-to-paid-pinterest-bug-bounty/111687) as an improvement to their security. Does it make sense for you?

There are some things to think about with implementation of HTTPS. Of course, there is a monetary piece to this. You have to buy a certificate for your domain so that HTTPS will work. Depending on the site you go to, these certs vary in price. The other big concern I often hear is about performance, that HTTPS will slow the site down and users will be unhappy. Recent advances in SSL and TLS have pretty much negated this issue. If a site like Facebook can implement it, there is a good chance you can as well. If you are serving up external content there may be some hurdles as browsers may get upset when trying to display mixed content: that is content from both HTTP and HTTPS.

I am not sure if it is going mainstream for all sites yet, or just the sites that have the sensitive transactions. There is a chance that it could make the switch. Another aspect is search rankings. Google has stated that it will rank HTTPS sites higher (http://www.zdnet.com/article/google-confirms-its-giving-https-sites-higher-search-rankings/). Is this the push that is needed? Is it enough to push everyone to HTTPS?

Welcome

Welcome to the brand new DevelopSec website. The goal of this site is to provide useful information for IT professionals to help develop better security practices. All too often, we see that there are professionals that are working very hard to create great products, but do not have the security information they need. Breaches are happening every day and many wonder why it matters. We hope to make an impact and show how we can learn from the breaches or other security incidents that occur so frequently.

The site is focused on helping the less security savvy professionals, the developers and testers and line of business. The intent is to provide valuable information without a lot of extra fluff. The site, while still under some construction, will consist of a few different resources. Over the past year, the DevelopSec podcast has been alive and well received. The podcast consists of 10-20 minutes of thoughts on different security topics. Thank you to all of you that have listened so far.

In addition, there will be a news section that looks at some of the incidents/breaches we see showing up in the news. There are a lot of places to get the news, and our goal is not to just share news stories. We want to go the extra mile and provide thoughts on how the situation in the news could effect you. Whether that means just some tips on how you might be able to reduce your risk of the same incident or a more detailed summary to provide a better understanding of the real risks.

Another section will be discussions on secure topics that will hopefully be beneficial to our target audience. Here is looking at what might evolve out of this new year in 2015.