You Dream it...We Build it... This is the second of 3 podcasts on the subject of "the security pyramid". This one covers the topic of "internal network policy". All of the material covered in the podcasts is also covered in the 5 posts listed below, although the podcasts often include items that are not in the posts. Thanks for listening!
Listen Here
This podcasts covers the first 2 sections of my recent series on the security pyramid, the introduction and the border patrol. The podcasts often include items that are not in the posts. Thanks for listening!
Listen Here
Is your site vulnerable to SQL Injection Attack? How about Cross Site Scripting? Are you even sure you know enough about those 2 vulnerabiities to protect against them?
This post is a continuation of a 5 part series on security called "The Application Security Pyramid". The introduction introduced a new metaphor for dealing with security that loosely mimics Maslow's heirarchy of self-actualization. In Part I I discussed the importance of "border patrol" technology to safeguard your network. In part II I discussed internal Policing and People Policy. In Part III I discussed the importance of managing the security framework of your actual application and how it relates to it's specific environment. In this, our final post in the series, we will discuss securing your application code itself.
This post is a continuation of a 5 part series on security called "The Application Security Pyramid". The introduction introduced a new metaphor for dealing with security that loosely mimics Maslow's heirarchy of self-actualization. In Part I I discussed the importance of "border patrol" technology to safeguard your network. In part II I discussed internal Policing and People Policy. In this post we will deal with the importance of maintinaing a secure "environment" for your application.
This post is a continuation of a 5 part series on security called "The Application Security Pyramid". The introduction introduced a new metaphor for dealing with security that loosely mimics Maslow's heirarchy of self-actualization. In Part I I discussed the importance of "border patrol" technology to safeguard your network. This post will deal with internal Policing and People Policy.
It's not enough to have effective border agents to feel safe. We also have to have effective policing inside our borders. After all, there are people here who are forced to work for the post office and they need watching. A system of policing and civil services keep us operating in safety and harmony with one another. This is the next two blocks on our pyramid - internal policing and people policy.
In my Previous Post I introduced a new metaphor for thinking about security. The purpose of this metaphor is to give us a framework for discussing the topic with stakeholders who have a cavalier attitude toward security, or who have fallen into the habit of relying on mere network security to keep them safe. We discussed how current metaphors that are physical in nature don't do enough to encompass the whole realm of security when it comes to addressing a specific application. A new metaphor is needed. I came up with a model based on Maslow's hierarchy of self-actualization (it sounds pompous but hey - it works for me). If you want to know more, read on.
CF Muse Reader Asks:
How do I educate my employer on the concepts of application security? How do I get them past the "We have a firewall and a DMZ, we're secure!" mentality? Specifically, in the past, I've tried using info from owasp.org to help, but they got "lost". Thanks Mark!
My first piece of advice is to never ever direct a non-geek to an open source project. You might as well be directing them to a site broadcasting Shakespeare in Hellenistic greek. Open source projects have a wealth of information, but the information usually isn't written very good... er... well (although I found this owasp.org site to be ok). Geeks use acronyms like Samuel L Jackson uses the F-bomb - often and gratuitously. Of course you can try to summarize what you learned - and it sounds like that is what you did. The owasp.org site starts at the application code level however, and is going to be difficult for any non-programmer to grasp - at least without some groundwork. Even though you are trying to get them beyond that "first level" of security in your discussion, you may still need to address it. So let's lay some groundwork.
CF Muse Reader Shane Asks:
Hey mark, I'm a frequent visitor to your blog. I'm curious what precautions I should take when dealing with storing credit cards in a MSSQL2000DB. I've done plenty of e-commerce solutions, but haven't done one where I need to store the CC's for many years. I know things have changed. Do I need to encrypt these? If so, what methods do you recommend?
Well this is a huge can of worms. In early 2004 (if memory serves) Visa required all its merchants above a certain threshold that sell on-line to be "certified" as "CISP" (Cardholder Info Security Program) compliant. Non-Categorized merchants - which may be defined as merchants with less than 6,000 transactions a year, no "hack" attempts (pretty vague) and who are not on Visa's radar - have avoided the cost of auditing by keeping a low profile while visa has other fish to fry - but the free pass may be coming to an end. Since "level 1" merchants are anyone that Visa says they are, they can require you to submit to an audit (at your expense) in order to continue processing Visa transactions. Wait.. it gets suckier....
Customers often show up on our doorstep with significant issues looking for a solution. That's a good thing. We like to think we can provide them. But so often there is a perception that there is one solution that is going to fix a particular problem. That is often not the case. The truth is that fixing a sick server or fine tuning an application or database may require many steps. When it comes to security this is especially true. Customers will often try to grasp security by fixating on 1 approach or 1 item that seems the most crucial to them. But there are no magic beans when it comes to securing your application. Just defining what the customer means by secure may be your biggest challenge.
This blog is a follow up to a previous post, on the Email Injection Attack exploit and its occurrence on CF servers. Several questions and comments that were added indicates to me that I wasn't clear enough in describing what I believe is actually occurring. Let me see if I can shed some additional light on the subject.
When it comes to security and the web there are a number of myths held by casual users. In the next several posts we are going to plow through them together and see if we can come to some conclusions on how best to advise our clients. The first, and perhaps the most ubiquitous myth, has to do with the efficacy of simply having a secure site.
(this blog is a follow up to Why the padlock is your friend)
When submitting personal information, most users know enough to look for that little padlock in the status bar that indicates a "secure" site. Most of them believe their information to be safe. They do not know why, but it has something to do with encryption doesn't it? Actually (and surprisingly) most web developers are fairly uninformed on the topic as well.
