Jul 04

Wasn’t This an Application Security Blog?

By terranceacrow | News

Yes, it was!

Interstell, Inc.’s adjusting its properties to better serves its customers, so this site, www.terranceacrow.com, is transitioning to a blog covering the challenges and jobs of writing novels.

Realigning Our Sites2

The application security material is moving (and we hope expanding!) at this site: www.interstell.com.

Please visit us there!

And if you’re interested in writing novels, please check back here from time to time!

 

May 11

Where Does a Developer Even Start?

By terranceacrow | Security Industry

One Day, It Dawns on You…

IsDangerousMuchlyLet’s say you’ve developed code for awhile. If a Project Manager, business partner, boss, or someone else with requirements comes to you, you can convert their business-speak into technical requirements. You can turn those requirements into an application that gets the job done. Customers love the results of your labor! As the accolades roll in, you’re probably feeling pretty confident.

Then you read an article like this one in CSO Online that says 736 million data records were exposed in 2015. Troubled, you put your developers skills to work and look for a solid, technically-recognized reference to explain how your baby might be vulnerable. You find Verizon’s 2015 report called 2015 Data Breach Investigations Report. You read. And you read.

And you read.

You study the charts. You match your business’ profile against the ones in the report.

You set the report aside, realizing that it’s good high-level data, but you need something more concrete. You find the SANS Securing Web Application Technology (SWAT) Checklist. It has seven sections and a total of 58 individual entries. The picture’s getting clears; it’s good description, but few code examples, and some terminology may be unfamiliar.

Undaunted, you cast around for something more focused and helpful for you as a developer. You come upon the Open Web Application Security Project (OWASP)’s Top 10 Vulnerabilities. Finally! A resource designed specifically for developers! There are some actual code examples! But after more review, some of the examples are aging or refer to products that aren’t being updated. Or the examples aren’t in a language that you are using.

If the data’s there, it’s not in a form that’s easy to get ahold of.

nicelittleappyouhavethereSo, after hours of careful deliberation and research, you come to the conclusion:

Crap. I’m doomed.

If some of the biggest companies in the world can’t keep their data safe…

If even some nation-states can’t protect themselves…

If the leading industry solution providers don’t have something that’s easy to consume…
Yet your application still needs to run on the internet…

What can you do?

The Truth Is… Well, You Know!

It’s out there (the truth, that is).

You know why validating data’s important for your application, right? You wouldn’t let someone enter a negative dollar amount in a gambling game. You wouldn’t let someone enter “99/aa/0998af” as a birth date. You wouldn’t let someone upload an EXE file instead of a JPG. You wouldn’t do these things because you feel responsible for protecting the data that comes into your application, right? You know that the wrong data results in the wrong outputs. And that makes customers unhappy.

At its essence, that’s security.

The data’s out there. It’s just not packaged for quick consumption — which is what you as a developer need.

Coding Your Way to a Better Tomorrow

surebeatswithoutapparelIf you know how to code, you can make your applications more secure.

And how to we do that?

It’s cliche, but one module/class/servlet at a time.

In the coming months, I’m going to share what I’ve learned after decades of coding for various companies representing financial and other well-regulated industries. I’ll give you examples that you can copy and paste into your code — or that demonstrate the basic concepts so you rework the example according to your needs. I’ll cover both Java and PHP. I’ll release the example code under the BSD 2-Clause License, which should give you maximum flexibility and freedom.

In other words, I want to give you tools to help you secure your code so your customers are happier, your boss is happier, and you can sleep better at night knowing you’ve done your best to secure your code.

You’ll add security to your perspective without even thinking of it as security. You’ll be back to converting requirements to your usually amazing applications. Only this time, you’ll know how to avoid the weaknesses that landed many companies in Verizon’s report. Will your code be unassailable? Good heavens, no! But it will be better. And not only better at a specific point in time: you’ll understand how to keep it as secure as is reasonably possible over the long haul.

Watch for the curriculum outline and some sample training videos/articles in the coming months!

Apr 12

Talking with Security Doubters

By terranceacrow | Techniques

Surrounded by Doubt…

In my last post, I talked about a scenario designers and developers know all too well: well-meaning management, project managers, architects, and business staff who don’t believe security is important — or don’t believe it’s important enough to warrant your time. Many of these doubters have direct input into the amount of effort you can spend on a project. If you’re a developer who knows what can happen when you ignore customer’s demands for reasonable security, what can you do?

Put Down the Stones!

nostonesFirst, let me address a tendency we have as developers. You are burdened with knowledge of how to get things done.* If you’re security conscious, you understand what insecure code or coding practices can do to customer trust. We tend to get frustrated or angry when people try to override our coding experience with their own priorities.

Becoming angry, though, won’t help. At best, they’ll just ignore you and label you a prima donna. At worst, they’ll just call you a prima donna and put you on work improvement because you’res not being a team player (in their eyes). But if (justifiable) anger’s not the answer, what is?

A Better Approach

Back in 1997, a modern philosopher named Don Miguel Ruiz came up with The Four Agreements to guide how we interact with others and ourselves. I’ve found them to be an effective way to advocate for security on behalf of the customer. Those rules are:

  1. Be impeccable with your word: Don’t be over the top or hyperbolic. Clearly and honestly state the requirements as you see them to your manager or team leader.
  2. Don’t take anything personally: Chances are, the folks arguing with you are just trying to meet their obligations and go home for the day. Unless you’ve knifed them (or one of their loved ones), it’s unlikely they’re attacking you personally.
  3. Don’t make assumptions: As developers, we tend to have a precise vocabulary. To my astonishment, I’ve learned not everyone’s like that (how do they even get to work without such precision?). Don’t assume they’re an idiot for not agreeing with you. Also, don’t assume you’re right! Even security requirements are subject to input from budget and risk. Management may have heard your pleas, considered them against the application’s risk posture and/or budget, and decided they could afford the risk.
  4. Always do your best: Represent your profession in the best way you know how. Don’t consciously exclude a security requirement without at least making your team leader or immediate supervisor aware. You could do worse than having the reputation as that “developer who’s always worried about security!” If you’re always striving for your best, you can still move your skills forward — even in a security-poor environment.

SometimesCantWin2Unfortunately, that last point is important: Sometimes, despite your best efforts, despite your eloquence and tenacity, despite your well-reasoned arguments and appeals to customer satisfaction, the team may decide not to incorporate the necessary security controls. They might elect to allow unfiltered input under the reasoning that the code uses stored procedures, so it’s safe. They might not understand that the input might include cross-site scripting (XSS) attacks that could ensnare a browser displaying the data. After all, security is only as strong as its weakest link. What can you do then?

As I see it, you have two choices:

  1. Accept the decision and keep working: If you enjoy working with this team, accept the decision and keep working. Certainly, keep a log of your concerns (e.g., keep the e-mails you sent warning of the security vulnerability) in case someone tries to blame you later. But otherwise, keep studying security on your own so your skills don’t stagnate. Also, hope the team will take your advice the next time!
  2. Find another job, give your two-weeks’ notice, and move on: If you find that no one’s listening, if you see customer data being compromised (especially if that data personally identifies a customer or reveals their health care data), it might be time to move on. You don’t want to lose your edge by working the architects, designers, or developers who don’t understand security. Again, keep a log of your efforts to make the team aware so they don’t try to frame you, but graciously move on. And don’t burn the bridges behind you! You never know when you might need to make a strategic retreat!

The real shame is that writing secure code is not materially different from writing insecure code. In fact, I’d argue that it’s actually less expensive, since the resulting code requires less operational support and is less likely to embroil the company in an inadvertent data disclosure. Those things take a lot of time to manage and correct! And that’s not even counting potential legal fees as the US Federal Trade Commission begins to get involved.

Always advocate for doing the right thing. It sometimes doesn’t seem worth it, but you have to live with you, so you might as well act in a way you can respect!

In the next post, we’ll take a look at giving your security concerns a sound foundation.

 

 

* After all, we’re the ones who tell the program exactly what to do and when to do it. The business team has more knowledge of why things are happening, but when it comes to exactly what’s happening, we’re at the epicenter.

Mar 11

Security: Not Just for Banks Anymore!

By terranceacrow | Justification

Let’s say you’re a responsible corporate citizen. You want to retain customers and attract new customers. Maybe you architect applications, maybe you design them, or maybe you code them. If you’ve every brought some aspect of application security — say, you point out it’s a really good idea to disallow cross site scripting (XSS) — I bet you’ve run into opposition like:

  1. We’re not a bank! We don’t need all that security.
  2. We’re not a military installation. Why would we waste time and resources on security?
  3. We don’t have any sensitive information. Why are you trying to slow the development process down with useless security?
We're not a bank! Why do we need security? Answer: You don't -- if you don't care about customers!

We’re not a bank! Why do we need security? Answer: You don’t — if you don’t care about customers!

Those might have been legitimate questions sometime in the past. When, I don’t know, but I’m trying to be charitable here. The point is, those questions are invalid now. Why?

  1. Money isn’t the only thing malicious actors steal. Personal information, log-on information ( typically an e-mail address), or even just source IP addresses can be useful to them. In other words, if you have an application on the Internet, it’s of interest to malicious actors. How will your existing customers react if your site’s compromised? Will such an event help or hurt future potential customers?
  2. Sure, securing military installations is critical. But so is securing your installation! Ask doubters this question: if a malicious actor were loose on your servers, what havoc could they wreak? How would your customers react to receiving spam from your compromised servers? Would potential customers be more or less likely to consider you if they know your reputation through spamming?
  3. Your site may not store personally identifiable information. You might not store financial information. But you store something — or you wouldn’t have an application! How would an existing customer react if they find their data spewed all over the Internet — even if it’s just a record of which cat pictures they looked at? Would you join a website that allowed such shenanigans?
Would you use a site that you can't trust? Would your customers?

Would you use a site that you can’t trust? Would your customers?

It’s not even accurate to say security isn’t optional. It’s more accurate to say that security is a requirement, just as important as any other business or technical requirement. Not taking security into account means increasing the risk of losing existing customers and decreasing the chance of obtaining new customers.

People who ask questions like the ones above simply don’t understand what they’re asking. We’ll talk about how to deal with them in the next post.

Jan 07

Content Coming Soon

By terranceacrow | Uncategorized

In the coming weeks, please expect to see training modules to describe how to protect your application against real internet threats. I’ll focus on two environments: PHP and Java/Tomcat. However, the concepts will be universal.

Plus, instead of providing isolated chunks of code that might be hard to understand out of context, I’ll provide working demonstrations that you can download and work with.

I’ve developed more years than I care to count, and I’ve seen technology change a lot. But one idea has remained constant: as developers, we want to write code that delights the people who use it. I’m going to show you how to make your delightful code even more delightful by protecting your users’ data, keeping it safe, and keeping it available to them.