Drop My Rights

I decided to do something a bit different this week. Rather than an essay on an InfoSec principle, I wanted to review and recommend a free product I’ve been using for a couple years.

Windows XP is still the most popular Operating System out there. And we still have way too many people running with administrative rights all the time. Drop My Rights is a free Windows XP utility offered by Microsoft that allows you to be logged into your computer as an administrator but run some programs with reduced privileges. I first heard about Drop My Rights on Steve Gibson’s Security Now! Podcast several years ago. Credit goes to Steve and Leo for introducing this to me.

Many of us get used to the convenience of always running our computers as administrator. Of course you need admin rights for things like installing applications and changing network settings, but you also need them for little things you wouldn’t think of. For instance, I’ve developed a habit of double clicking on the system clock to pull up the calendar. I use that to quickly scan forward or backward to look at dates. That activity is actually unavailable for standard users.

Drop My Rights lets me continue running as an administrator while running high risk programs like Internet Explorer, Firefox and Outlook with reduced rights. Below, I will give a brief explanation of how to configure Drop My Rights and resources if you’re looking for more information.

Download the installer for Drop My Rights from: http://download.microsoft.com/download/f/2/e/f2e49491-efde-4bca-9057-adc89c476ed4/dropmyrights.msi

Go through the install process. I recommend you select defaults except to change the install path to something easier to remember, because you’ll need to use it later. For the purposes of this article I will use c:dropmyrights.

Next, you will need to edit shortcuts that will open your high risk applications through the Drop My Rights context. I am going to set up Firefox. Right click on shortcut and select Properties.

Once you’re in the Properties Windows, in the Target field move your cursor all the way to the left and enter: C:dropmyrightsdropmyrights.exe

Change the “Run:” field to “Minimized” so that you don’t need to see Drop My Rights pop up whenever you use that shortcut.

And, Bingo, you’ve got Drop My Rights configured for that shortcut. For some programs (like Internet Explorer) you will need to go find the Icon again so the shortcut looks like, but Firefox doesn’t lose its appropriate Icon.

Firefox instances started from that shortcut will not have administrative rights. If a piece of Malware tries to perform an installation it will fail due to insufficient privileges. I recommend editing all your commonly used shortcuts in this way, then if you really need to run Firefox (or IE, etc) as an administrator you can go to the shortcut under Start/Programs and intentionally run with elevated privileges.

You can find more information about this tool, including technical details and options for switches here: http://msdn.microsoft.com/en-us/library/ms972827%28printer%29.aspx

Connect with


InfoSec was created for the business

Not the business for InfoSec.

The problem

Information security practitioners come in many different types. There are the IT risk assessors who have never set a static IP address and firewall admins who have never heard of residual risk. From security administrators to compliance officers, information security wears many faces. Regardless of what domain is the emphasis, information security has one primary goal: Serve the Business.

Yes, that probably seems obvious. They’re paying you to be there, so you ought to do your best to support the company. But it’s human nature to see things through your own lens. An individual’s area of expertise is most likely to be the area that individual deems most important.

The leaders of an organization have many concerns to balance. Take a few major threats facing an airline for example:

  1. Gas prices rise, and we lose money on tickets we’ve already sold
  2. Gas prices fall, but we pre-paid for gas, and now our competitors can undercut us
  3. Disease scare, nobody wants to fly
  4. Terrorist scare, all flights shut down
  5. Low-price competitor moves into our region and takes our market share
  6. Pilots/mechanics/flight attendants go on strike

The list can get much longer (and more accurate I’m sure), but the fact is, the top threats to an organization are not technical in nature. They are determined by the landscape of their industry.

As information security practitioners it’s our responsibility to find and report technical vulnerabilities where we see them. I believe we are good at this. It’s what we enjoy. But after we have reported the vulnerability and made sure its risk and scope are known, it’s no longer in our hands. The business must decide which risks to mitigate first.

What does this look like in real life?

You find a huge SQL injection vulnerability in your company’s publicly accessible web application. You have figured out a way for an authenticated user to return the financial records of all your customers. You type up your finding, schedule a meeting with executives to report the issue, and eagerly await the word that it will be development’s number one priority. But, for some reason, the developers are not jumping directly on this finding. They’re still working on that new product that is due to ship next quarter.  You see this happen a few times and become disheartened. It’s at that moment you need to remember: information security exists to serve the business, not the business to serve information security.

You were not a part of the meetings, but the executives weighed the risks and rewards of going forward with their new product launch versus fixing the bug you found. What they know, and you don’t, is that if they don’t get that product released on time they lose market share. That new product will infuse the company with the cash needed to stay afloat (and keep your job). The impact of someone exploiting your vulnerability may be high, but the probability is low, so it needs to be pushed off.

Maybe your company gets breached, maybe it doesn’t. But at least the company survived to address the breach, instead of missing payroll and closing the doors. It’s still there to address the issue and move forward. These are the types of difficult decisions the business leaders have to make.

Who are you anyway?

A good information security practitioner is more than technical. We need to be business people who happen to have technical skills. It is our job to inform management of the risks and educate them on the solutions, but it is management’s job to prioritize and provide resources.

Connect with

Implementing Application Security Part 3

This is the final installment of a three part series of thoughts on implementing an AppSec program at an organization.
For Part 1 click here: Implementing Application Security Part 1.
For Part 2 click here: Implementing Application Security Part 2.

Get Proactive

Don’t wait for your users or the hackers out there to find the vulnerabilities in your app. You’ve got a good selection of tools at your disposal. Use them all in the right way.

Black box scanning: Don’t count on black box to get you very far, but don’t assume it’s worthless either. These types of scans are usually the easiest and cheapest to run, and you can have them run on a schedule without any human input. Get used to reading the reports; know what it says, then when something changes in your environment you can pick up on that immediately in the report and research what changed.

Code reviews: Code reviews aren’t the easiest part of the program, but they are one of the most important. Your development team is responsible for all the code it produces. Code reviews are a good way to ensure that the team sees what it’s releasing. It can be the entire team going over selecting high-impact portions of code, or one individual reading through another’s code before it gets pushed into service. Figure out a review schedule that works in your workflow and get it going.

3rd Party Pen Tests: An external pen testing company can be a good way to have the security of your software verified. Get them in the environment and let them see what they can break. Be sure you’re working with good pen testers. Ask what kinds of activities they’ll be doing. Someone who just runs application testing software against your site, then cleans it up for a report, isn’t giving you a lot of value. Find someone who will be using a combination of tools and manual hacks to go after your site.

Application Firewalls: An application firewall is not a cure-all. You cannot throw this in front of an insecure app and expect to fix the problems with it. But a well configured application firewall can be an effective part of your security. You will need to tweak the firewall for your application to teach it what normal behavior is. The proper tuning of an application firewall can be as complex as coding the program itself, but it can be worth it. In the end you get another layer of protection that is programmatically diverse from the application it’s protecting.

Summary: How a good application security program looks in practice

Good application security begins even before the first requirement is written for a project and does not end until the last remnants of the project are end of life.

  • Executives who believe in information security push down corporate policies that include security goals for executives, managers, developers and QA.
  • Software architects with good security awareness and appropriate technical security training determine the right architecture to meet all business requirements for a project.
  • Requirements are documented for the new project and security requirements are right there next to the functional requirements.
  • Developers who are trained in the secure coding techniques, and who have been told that creating secure code is a priority, implement secure code.
  • QA analysts go through their test script ensuring the application functions appropriately, run their security tools, and use their experience to look for vulnerabilities while they test functionality.
  • Regular code reviews, web scans, and penetration tests work to find new vulnerabilities before the bad guys do.
  • Internal audit ensures that technical teams are adhering to their stated information security standards and procedures.

Well, that’s my take on implementing application security. Let me know how you’ve implemented AppSec in your organization.

Connect with

Implementing Application Security Part 2

Here is the second of a three part series of thoughts on implementing an AppSec program at an organization. For Part 1 click here: Implementing Application Security Part 1.

Step Three: Process

Build security requirements alongside functional requirements in the business requirements.

Functional requirement:

“Needs to be viewable in three languages”

“Must allow users to set their own color theme”

Include security requirements like:

“Passwords must be changed every 90 days”

“Only authorized personnel may view data X,Y,Z.”

By including these types of security requirements from the very beginning of the process, the developers know what’s expected of them and can be game-planning how to deal with them all along.

Embed security checkpoints into the development cycle. After creating security requirements, you don’t want to just assume they’ll be successfully implemented and wait for QA to tell you at the end that the application is not meeting the security requirements. By including security checkpoints in the development cycle, developers will keep these requirements in mind and increase the likelihood that your security is integrated and successful.

Determine metrics for success in secure development. Whether it is bugs per 1000 lines of code, percentage of security requirements met, or another metric that makes more sense in your environment, find a measurable way to report on the effectiveness of secure coding guidelines at your organization.

Implement performance objectives around secure coding. These objectives should be explicitly outlined in the employee’s goals. Give ongoing feedback on the developer’s success during the year. Don’t surprise him with either success or failure. Seeing these metrics and goals on a regular basis will keep application security top of mind.

Provide rewards. Research shows that in order for negative consequences to impact behavior they have to be applied at a much higher rate than positive consequences. So, rather than punishing those who do not follow security guidelines, give perks to those who are successful. A few free iPads will both get a whole development team on-board with security, and it will make the InfoSec guys look more like the good guy instead of the bully with a big stick.

Step Four: Testing

Get security involved at the very first architecture meetings. Talk about how the types of architecture you are using for the project will interact with one another. Figure out what unique vulnerabilities your product is going to have.

Work on threat modeling with not only the application architects and developers, but get the business owners involved as well. They know better than anyone else what the system is supposed to do and what constitutes an abuse case. While your developers might be able to prevent code flaws like XSS and SQL injections, they cannot help with all the potential logic flaws in a program. If the business doesn’t help think of the threats, even the best developers can’t make secure code.

Encourage developers to make unit testing for their code. Unit tests are not the end-all be-all, but in some cases they can help identify exactly when and where code is broken. By continuously running unit tests on their code, developers will be more aware of the impact and breadth of their changes.

Train up your QA team. They need just as much security training as your developers. They must know how to recognize potential security issues and know how to exploit them if they exist. Find automated tools for QA (you can start with something as simple as Nessus), and teach them how to use the tools. From there you can start offering them training on manual and more complex tools for testing. A well trained QA team should be the first (and only!) people to find any security issues that make it through development. A combination of scanning tools, penetration testing tools, and manual testing can help point the development team in the right direction before a vulnerability is exploited and splashed all over the internet.

For Part Three click here: Part 3

Connect with

Implementing Application Security

In honor of attending the Front Range OWASP Conference (FROC) today, here’s the first of a THREE part series of thoughts on implementing an AppSec program at an organization.

Step One: Executive Buy-In

The first step, and most important aspect, of implementing application (or any other) security measure is receiving buy-in from leadership. The business leaders push down the priorities all across the organization. If the leadership support stops a level or two below the CEO, your security program’s scope will be severely diminished. A CISO or CIO may have the power to push out requirements to IT, but if you want information security pushed across business units you will need support from the CEO, CFO, or COO.

All leaders are going to agree with the idea of information security. They have seen the results of poor security in the news in the TJX and Heartland cases. While hearing those types of stories can bring great attention to information security needs, it’s not fear mongering we want to do. We want to move beyond a CYA approach and present the business risks, including the costs of a potential breach versus the costs of a countermeasure, and help our organizations leaders make educated business decisions. Getting executive leadership to buy off on an integrated security program takes more than a 30 minute meeting filled with horror stories. It takes an ongoing relationship with the InfoSec professionals based on trust, not fear, and an understanding of the scope of the business risks associated with data protection.

The executives do not need to know every detail of how security is implemented. Getting to that level is probably a waste of their time. But they do need to understand the importance of security and how that ties into producing high quality products, and providing high quality service to clients.

Working closely with the highest levels of leadership can be daunting. Their calendars are often full, and difficult to get onto. Work through your chain of command. I am not suggesting you march into the office of your CEO. Build a coalition among your boss and his/her boss.

Step Two: Education

The education of staff is the next step. This starts at a very high level for all employees but gets down into technical curriculum as necessary. Each employee needs to know not to click on phishing emails or send out client’s personal information. But maybe only the development and QA team needs to be trained on the Software Development Lifecycle. And while the standards for data input validation may be applicable to all, the techniques used for preventing buffer overruns are of no use to the .Net and Java developers. Just like your client/server developers don’t need Cross Site Request Forgery training.

Implementing training that is timely, specific and personally meaningful for each team is critical. Generalized trainings for an entire IT department are going to lose 90% of your audience for 90% of the time. The QA folks will snooze through the network security talks. The help desk will fall asleep during discussion of development standards.

To manage so many diverse training needs, the tasks of determining curriculum must be handled, at least in part, by a member of each team. An InfoSec professional working with a developer can craft great training that will have targeted impact within that development team.

This type of formal training should be performed at least annually. On top of that, you want to provide learning opportunities more often for team leaders, those in fast moving technologies and other interested parties. Organizations like ISSA, OWASP, and SANS are great ways to keep the in-the-trenches IT workers interested and up to date on security threats without breaking the bank. If budget allows, sending employees to training classes can be a great reward and a way to let employees know the organization wants to support their career growth, at the same time increasing the employee’s value to the organization.

Click here for Part 2 of Implementing Application Security.

Connect with