Given that a big part of my job is to teach programmers how to build secure software, I recently asked for help from a community of sysadmins. I wanted to know, given their experience deploying, maintaining, and securing application software, what one thing could developers do to make their jobs easier?

Here was my post:

 Subject: If you could tell a programmer one thing...


 For those of you who don't know me, I spend a lot of time writing and teaching security topics,
 and my audience is mainly composed of programmers.


 Last year I left my former training company where I was in charge of the security curriculum.
 I've been working with a new company (Pluralsight.com) where I'm busy developing a whole new curriculum.


 One of my goals is to make sure each programmer leaves knowing basic security principals
 such as least privilege, defense in depth, CIA, and so on, besides all the gory details
 we go into WRT programming Windows and .NET security APIs.


 I've been lurking on this list for some time, and it seems like many of you guys are administrators,
 or involved with system administration in some way. My question to you is, what security topics
 do you think are important for programmers to be aware of? Or put another way,
 what can I teach that will make your job easier?

Below are some of the responses. Please feel free to add your own comments (just double-click this page to edit it). I'd love to hear about your experience as a sysadmin, and what sorts of things you'd like to see programmers do better.

Threat modeling.

"You're not good enough." You are not good enough, as an individual or a team, to catch every bug in detail. As a result, you have to cast several nets for those bugs - check on the inside of functions that your parameters are good, and your returns are within range; check on the outside of functions that you're passing good parameters, and that the return values are within range, and keep doing that.

"Input is assumed to be evil; everything that isn't in your source code is input." That means keypresses, mouse clicks, network traffic, disk files, email, even Window messages (remember "Shatter"?) - it's all input, and unless it came from the source code you typed in, you must validate that it is good for operating before you operate on it.

"Generate good output, even if the reader for your output accepts less-strict output." A re-writing of the old Postel mantra, "Be liberal in what you accept, conservative in what you send".

"Assume that it's exploitable." If bad input can make your software do something it's not supposed to, start from the assumption that it can be exploited to do anything the attacker wants. Only relax (if that's the

term) when you have proven that the attacker has no ability to push it past a mere incorrect result.

"Writing Secure Code" should be given out at the start of the course.

Tell them that even small businesses are paranoid.

Tell them to code for "designed for Windows XP" at a minimum [item 3 - run as user if I remember right]

Tell them to stop coding for Windows 98.

Tell them to disclose ON THEIR WEB SITE what ports/special setups are needed for the software and no, poking 100 holes in a range of ISA server is not acceptable.

I have been saying for ages that I think developers should spend some time being a network administrator so they know how damned awkward it can be to deploy some software and how easy it can be when the developer's done the right thing.

I've had to install three new pieces of software recently -- one for digital dictation, a personnel system and a piece of bulk scanning/image processing software. All three of them shared the following characteristics:

a) Wrote data to the tree

b) Wrote user settings to HKEY_LOCAL_MACHINE

c) Used non-standard temporary directories, or required non-standard folders to be created on the C: drive.

I gave all the vendors a hard time. For the last one, the guy wanted to make users local administrators because that's what his instructions told him to do. Obviously, I refused and he came back with the folders and registry keys that needed their permissions relaxed.

We shouldn't be doing or tolerating this in 2005.

Why can't developers understand the difference between a user and a computer? Is it really that difficult?

I'm not a sysadmin, but I'd tell them:

1) Don't write your program so only administrators can use it. Make it work easily at the user level. If all Windows programs were like that, we might actually get users to stop running as root.

2) Don't have your program automatically start with Windows unless it is necessary and expected. Don't have it run as a service for the same reason.

If these are necessary, make it clear.

3) Have a good and thorough uninstaller.

4) Work closely with the guys who are going to write the Help files.

Don't assume you won't screw up. You will, so prepare for that day by making sure you can amputate bits that suddenly become a problem.

Ensure that all the following locations can be controlled independently...

• where your program installs to (code)
• where the data goes (backup)
• where incoming material arrives (risk)

...and do not smudge these into each other, ever.

LetTheUserDrive (somewhat long, but really insightful post)

We are tired of hearing about how "it works" on your development box. You don't know the configuration status of your box. You aren't built to the standard we have live by. Even if we share that standard with you. you deployed all your components on one box and never had to worry about security and user credentials. Thus, you don't have them documented and we will have to discover them as we deploy your crap.

We are jealous of MSDN because TechNet has sucked so bad for so long. But we know when you are deploying code based upon Samples written for expedience to demonstrate technology X while "pwd=password".

Please...Create a silent installation package. Create good installation documentation. Limit the TCP/UDP ports your program uses. As a programmer, assume your software will need to be installed on 50,000 systems yesterday. Do not assume the software will be installed lovingly by one person who is paying attention to each installation setting, but by a frustrated SysAdmin who was told to get your software on every system by tomorrow morning. We want to be able to figure out the default settings for our users and then remotely push this software down to each system and at the end feel comfortable that each of the 50,000 users will open your program without issue.