Slashdot Log In
Developing Securely In Windows
Posted by
samzenpus
on Mon Nov 21, 2005 01:47 PM
from the the-secure-collective dept.
from the the-secure-collective dept.
FrazzledDad writes "No, really. Please pick yourself up off the floor and stop laughing. Yes, there are good books on developing Windows software in a secure fashion. Keith Brown's The .NET Developer's Guide to Windows Security is right alongside Howard and LeBlanc's Writing Secure Code as examples of good Windows security works. Brown's book should be on any .NET Developer's bookshelf and will be of use to developers who work in other development platforms on Windows." Read on for the rest of the review.
I know the entire topic of Windows security may kick off a "slightly" enthusiastic debate among Slashdotters. I'd really prefer not to get wrapped up in a fray, so let me just say that a professional software developer needs to well understand the security issues in the environment and platform they're working on. This book's an important aid in that understanding. Great Fundamentals
Brown's book is broken into six parts, ranging from "The Big Picture", an overview of security on Windows, to "Access Control" and a wrap-up "Miscellaneous." Each part is made up of numerous "items," one topic which Brown elaborates on.
Brown covers a lot of very basic, important fundamentals such as "What is Authentication?", "What is a Luring Attack?", and "What is Kerberos?" He gives concise, clear overviews of each topic, then gets into the weeds where necessary.
For example, one of Brown's first emphatic points is that development on Windows platform shouldn't be done using an account with Administrator privileges. He covers the "why" in several early items, then spends 11 pages in Item 9 showing the approaches, tools, and issues involved in developing under a non-Admin account. This particular item needs to be stapled to far too many developers' foreheads because they don't understand, or care about, the ramifications of development as an Admin. Great Details
Brown also goes into great detail on many Items. His discussion of IPSEC is a good example. He spends Item 68 on the fundamentals of IPSEC such as key exchange and authentication, then goes on in Item 69 to discuss the details of implementing IPSEC via policies in a domain. He covers client and server configurations, then gives rationale for selecting various options. He also talks about why it's not the best solution, or even a complete solution, but does point out where IPSEC makes sense.
COM programming gets an entire section/part to itself, and Brown does a great job explaining the complex issues surrounding securing COM(+) communication. He discusses Authentication, Impersonation, and what calls you need to make in your Main method to properly invoke various COM security aspects.
Threat Modeling gets its own Item, but isn't covered in great depth. Brown lays out Microsoft's STRIDE system (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege) as a guideline for threat modeling. He also talks a bit about attack trees. Neither topic gets substantial treatment; however, Brown makes it clear he's only introducing these topics and points readers to several other resources such as Swiderski and Snyder's Threat Modeling. Great List of Cons and Problems
Part of good software engineering is understanding the ramifications of choices you make. Brown's very good about laying out the "Why" for his items, plus he's also clear where hard choices have to be made.
For example, in his discussion of IPSEC he asks "Where is IPSEC useful? When you don't have any better alternatives." He goes on to show how IPSEC can be used to help COM servers talk securely, or in .NET Remoting under the 1.1 Framework which stupidly doesn't provide secure communication channels.
Another example might be the erasability of a secret under .NET. Managed environments such as .NET and Java don't make it easy to ensure secrets (passwords, keys, etc.) can be erased out of the managed memory heap or at least overwritten immediately after their purpose is fulfilled. Not only can the object's memory be left unerased, but what about controlling whether it's written out to a swapfile? Brown points out these sorts of issues and tries to point out how to deal with them. What the Book Doesn't Cover
Brown's book isn't so much about specific coding techniques, although there are a fair number of those within. You won't find specifics on .NET's code access security, or issues around cross-site scripting. You'll need to look to Howard and LeBlanc's Writing Secure Code for code specifics.
Rather, the book is more about approaches to secure development on Windows. Brown's book also isn't about security and threat analysis, but again, he's forthright about that and points readers to other sources.
Bill Wagner, author of Effective C#, points out on his blog that Brown's book would be more usable if "titles [were] organized around the tasks I need to perform." I think that's a good criticism - a cookbook format would be a great improvement for a second edition. Summary
The book's very well written with a good index and a terrific Bibliography which serves as a great reading list for furthering one's knowledge of security on the Windows platform.
I've found the book very educational and useful. It's an important addition to my bookshelf and has already helped me with a couple of important topics. I think any professional, contentious developer working in the Windows environment would find this a vital addition to their bookshelf as well."
You can purchase The .NET Developer's Guide to Windows Security from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
World's Shortest Books (Score:5, Funny)
From Amazon.com:
Customers who bought this title also bought:
Re:World's Shortest Books (Score:3, Funny)
Re:World's Shortest Books (Score:2)
and find out your system still isn't secure.
I have this on my bookshelf... (Score:2, Funny)
Here's a thought (Score:5, Insightful)
Re:Here's a thought (Score:3, Insightful)
Re:Here's a thought (Score:2)
Re:Here's a thought (Score:2, Interesting)
That doesn't mean it should not be considered... Well, people are going to get drunk, and drive anyway, should we just eliminate the laws making it illegal?
Re:Here's a thought (Score:2, Insightful)
Re:Here's a thought (Score:2)
Re:Here's a thought (Score:2)
By the time I finished reading your post I thought of two attack vectors you neglected.
1) The TCP/IP implementation (usually implemented in the....Operating System!)
2) The firewall implementation.
I'm sure if you give it ten minutes thought you can come up with many others.
The O/S is important.
Re:Here's a thought (Score:2)
I didn't mean to infer that there weren't possibly other means of attack, so much as that they are much less a possibility... I'm not aware of any attacks exploiting the windows tcp/ip stack directly...
Re:Here's a thought (Score:2)
I'm afraid you recall incorrectly. Read this slashdot thread [slashdot.org] to get more info - but essentially, whilst there is plenty of BSD code in microsoft products, its unlikely that they used a bsd based tcp/ip stack in windows versions beyond NT3.5.
beyond this, I never said the firewall was software and ran on the windows machine...
Where they are running is irrelevant to this discussion.
for that matter, there's also router attacks, and other types of DOS att
Re:Here's a thought (Score:5, Insightful)
However, I have to submit that most of the time security exploits in windows, are user initiated. Reduced privileges for default users would be a great improvement.. aside from that, we must bear personal responsibility for what we create.
Parent
Re:Here's a thought (Score:2)
Someone who has a mediocre grasp on system configuration can lock down a Windows box pretty easily. When we think of Linux this is a given because for the most part clueless users wouldn't be using Linux to being with. Though if I just threw up some Red Hat 7.x box right now on the net
Re:Here's a thought (Score:4, Informative)
Hmmmmn....How about if I change your statement to:
A solid piece of software is just as impenetrable on Windows 95 as it is on Windows XP Professional or any other platform
This statement is incorrect - Windows 9x Filesystem (for starters) makes your program's config files (or hell binary) overwriteable by anyone in the system.
So you see - the OS is important.
Parent
Re:Here's a thought (Score:2)
Re:Here's a thought (Score:2, Insightful)
Re:Here's a thought (Score:2)
My modpoints ran out just as I was about to bump you up, but then, it looks like you're sufficiently well bumped by now anyway.
No platform is or will be 100% secure, but that doesn't and shouldn't stop engineers from reducing the number of security holes.
Re:Here's a thought (Score:2)
That's only true to a point. It's like having a VERY sturdy roof on a framed house with holes in your studs.
Re:Here's a thought (Score:2)
http://www.microsoft.com/uk/press/content/pressce
Re:Here's a thought (Score:2)
After getting pwned, give them the precision that you're not allowed to actually put anything INTO the sand, and watch them try to design some kind of floatable device on top of which you may be able to build your fortress for some time before they burst in tears.
It only works if you read it before hand... (Score:3, Insightful)
Just putting it on the bookshelf won't help - ya need to read it before you put it there.
On a related note, this pretty much rules out all the developers I work with - if you can't get it as a Book-On-iPod, they aren't interested these days =-)
Anyone else see (Score:2)
Or maybe making it unmaintainable is just a sneaky way of developing securely...
the
Why should I be laughing? (Score:5, Insightful)
I'm not laughing (Score:3, Funny)
I am forced to develop windows applications from time to time, and I am ashamed of the poor security of many of these apps. It is definitely something that should be addressed. There are hundreds of thousands of part-time windows developers who know even less (gasp!) than I do about security.
/me gets back to hard-coding plaintext database passwords.
secure windows code (Score:2)
http://www.apple.com/macosx/applications/office/ [apple.com]
start with an interpreted environment. (Score:5, Interesting)
At least with a managed environment, you have less chance of attack channels which result from unchecked data. You still have to consider how software is used, what it connects to, and check data going to an rdbms in environments that don't do it for you (parameterized queries for ADO.Net are pretty nice).
Let me guess??? (Score:2, Funny)
a conversation (Score:5, Funny)
SA: Hi, I'm busy.
CWS: HEEY! Look at me!
SA:Uh-huh.
CWS:You sure are secure aren't you?
SA: Sure am.
CWS: Hey, let's see which one of us is more important!
SA: Whatever.
CWS: MR PROCESS MANAGER!!! WHICH ONE OF US IS MORE IMPORTANT???
Windows PM: It looks like you're trying to type a letter...
CWS: YAAY! You know what,this sucks, I'm just gonna take all of the CPU cycles and all the network bandwidth now!
SA:...!!...No..Must...keep......working..m....u..
Windows PM: Well, it looks.... like you guys..... are busy, I'm gonna take a n......ap. Wake me up if anyone starts writing............... letters.kbyethx...
BSD: "Pleased to meet you, Hope you've guessed my name..."
Re:a conversation (Score:2)
>Windows PM: It looks like you're trying to type a letter..
I think we're missing the point here... (Score:5, Insightful)
The point is making sure your app is NOT the weakest link here, i.e. allowing a virus to inject code thru a buffer overflow or something. And we're living in post-Sony times, it was bad enough with viruses - just wait till the rootkits start spreading.
Attack trees (Score:2, Interesting)
Where they're even known about, say by people who have read Secrets and Lies (Schneir 2000), far too many developers are forced to reinvent the wheel. This hurts security in a fundamental way. All too often, they've never been heard of. I'm glad they're getting some mention, on any level.
Re:Attack trees (Score:3, Funny)
They be Ents Mr Frodo
No, really (Score:4, Insightful)
Re:No, really (Score:3, Interesting)
What, people won't take
-jcr
Hate to do this but (Score:3, Interesting)
Remember this is to build secure software on Windows, something that should not be frowned upon even if those who write Windows don't listen to this advice. So when your next Window app breaks and your customer is irate, you can say "uh uh that's MS Slammer 5002, that's a bug with Windows not my code buddy!! I know my shit and that's why you're paying me too much to do this, now stop bugging me already, don't you accountants do anything but make cups of coffee all day!!!!"
Read the Book.
Developing Secure Software (Score:2, Insightful)
Free Online (Score:5, Informative)
Wndows=security? (Score:2)
fatal error segmentation fault
Re:Wndows=security? (Score:2)
Attack Trees effectiveness (Score:4, Funny)
Didn't Gandalf use the assistance of Attack Trees to topple Isengard? Sarumon really needs to read this book.
But seriously folks....another good reference here:
http://www.microsoft.com/MSPress/books/5957.asp [microsoft.com]
Steps one through four (Score:3, Funny)
Step two: Shut down
Step three: Use power button to kill hung shutdown
Step four: declare victory! you have successfully secured windows
Re:Steps one through four (Score:2)
You forgot to try to play the Final Fantasy victory theme as part of step 4, and suddenly realize you just turned off the house's only audio player*... ;)
*for smarter people, this might not apply
a secure windows program (Score:3, Funny)
{
return 0;
}
Re:Of course it's possible (Score:2)
Re:Of course it's possible (Score:2, Funny)
That would be so much funnier if IIS 6 didn't have so much better of a security track record than Apache has over the same period.
Re:Cue jokes... (Score:2)
Isn't that rather like giving credit to someone who quits mugging, when credit should be given to those who have never mugged in the first place?
Re:Cue jokes... (Score:2)
Re:No such thing .. (Score:3, Insightful)
Does this mean that any system with bugs is not worth developing for? And if this is true does it mean that developers who code third party software should be absolved of any wrong doing? That's just nonsense to me. MS may not have a great product out there on the terms of security but the kind of retards at AOL who are coding weakly and creating a number of the exploits being used certainly are at fault.
If we hold ou