Slashdot Mirror
Developing Securely In Windows
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.
The .NET Developer's Guide to Windows Security
author
Keith Brown
pages
408
publisher
Addison-Wesley
rating
9
reviewer
Jim Holmes
ISBN
0321228359
summary
Terrific coverage of how to go about securely developing .NET software
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.
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.
From Amazon.com:
Customers who bought this title also bought:
...next to "Building Castles on Sand".
There's Firefox and Apache for Windows, isn't there?
Instead of bashing MS and Windows, prove that you're the better programmer by compensating for the sometimes flawed security. If you don't think users can trust their OS, at least you can take pride in the fact that they can trust your software running on it. A solid piece of software is just as impenetrable on Windows as it is on Linux or any other platform - it's all about understanding the environment. Looks like a great book, thanks for the review.
Rex is 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Brown's book should be on any .NET Developer's bookshelf
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 =-)
"Murderer? Well, that's a harsh word. I prefer to think of myself as a Mortality Technician."
Windows has come a long way in the last 5/6 years and vista should ship reasonably secure out of the box. It's still an unbelievably shitty OS peddled by an objectionable bunch of borderline criminals, but you have to give them credit for addressing security issues.
Anyone else see the irony in having two articles on the front page of /. one of which is about secure coding and the other which is about "How To Write Unmaintainable Code"
/. editors are sneakier than i gave them credit for
Or maybe making it unmaintainable is just a sneaky way of developing securely...
the
[Fuck Beta]
o0t!
Can you point me to any OS where security is automagic and the developer doesn't need to consider it? Windows may have its problems and more than enough shitty architecture, but security must be considered in the design of Mac and Unix/Linux programs as well.
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.
Man, you really need that seminar!
Managed environments like .Net, Java, Python, etc. are a good start, but aren't the end of things. Most principles in security are similar regardless of platform. I do think a lot of the issues in windows security come from poorly written software that doesn't work properly in reduced security contexts... It's nearly impossible to develop on windows without administrative access to the machine you're working on.
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).
Michael J. Ryan - tracker1.info
Chapters 4-6 deal with setting up VMware on linux?
CWS: Hello secure app, I'm coolwebsearch!. ....sT...... ...
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..."
If you don't know what AltaVista is (was), get off my lawn.
A chain is as strong as its weakest link.
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.
"He also talks a bit about attack trees." but doesn't discuss them thoroughly. I wish somebody would. I *really* wish there were a Web site devoted to them--something like design patterns. Perhaps powered by a Wiki.
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.
What you do with a computer does not constitute the whole of computing.
"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." With snippets like that starting off an article, you start to see why people have trouble taking Slashdot seriously. This is getting ridiclous, almost FOXNEWSesque.
this book can be read online for FREE as in beer or something. If you want it in one document you may have to get your "copy and paste" on, or if you are in hacker fever you could screen scrape it. Anyway http://pluralsight.com/wiki/default.aspx/Keith.Gui deBook.HomePage yep all there for your Windows security mokery.
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 should always be platform independent. But security for developing an application does not stop at the developer, it continues through to the system administrators and the users. We've all heard software is only as secure as the O/S its running on, well its also as secure as the administrators/users running it. Security should be practiced at all levels from development to roll out and installation and through its entire lifetime. No software is completely 100% secure, so if flaws pop up after development patches should be available ASAP.
GL HF!
The book was developed online via a Wiki, available here for free. This is a great book that every windows and .NET developer should be aware of.
SELECT * FROM Windows WHERE security > 0
fatal error segmentation fault
"I bow to no man" - Riddick
"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."
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
He who knows best knows how little he knows. - Thomas Jefferson
Step one: Unplug from network
Step two: Shut down
Step three: Use power button to kill hung shutdown
Step four: declare victory! you have successfully secured windows
I think the solution is to only develop Microsoft applications that are specifically designed to run on Mac OS X.
http://www.apple.com/macosx/applications/office/
He who knows best knows how little he knows. - Thomas Jefferson
int main( int argc, char** argv )
{
return 0;
}
If the underlaying closed source API has bugs there's nothing much you can do about it.
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 ourselves to only the highest acheivements of the worst developers we're all going to be in trouble.
And what of those that have to use Windows? You may sit high and mighty and laugh about this but some of us are paid to code for Windows. Are we suppose to go find all those Linux jobs that I keep hearing of just because MS writes bad code? That's like quiting a company after finding that a CEO high up embezzeled (sp??) funds.
Dedicated Cthulhu Cultist since 4523 BC.
The Encyclopaedia Galactica, in its chapter on "Developing Securely In Windows", states that it is far too complicated to define. The Hitchhiker's Guide to the Galaxy has this to say on the subject:
http://outcampaign.org/
I wish you could be modded even higher than five. Everyone's reply seems to be that there's no point or abbility to write secure windows code becasue windows is insecure. Just because a system is vulnerable doesn't mean you can't make an effort not to provide any extra holes.
If someone wants to attach your padlock to their paper door that's their problem, that's no excuse for you to build a padlock that can't be closed.
I assume by that you mean on the "criminal" side of the border.
was "I do the VeeBee."
:-)
While the fact that they were foreigners didn't help their communication skills, (Hey! I learned English, they could too,) they were just average schlubs who thought that taking a course in Microsoft VB would land them a career in software development.
By the time I had disabused them of the idea of a career in software development by asking questions which should have made it clear that "doing the VeeBee" is not a qualification for anything, I wiped my hands of the whole thing.
If a little knowledge is dangerous, these guys needed handling with wired, extremely remote waldoes.
These people were a hazard and harmful to themselves and to their potential employers.
I sent them to competing consulting firms
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
That one ep where Max spends like 20 minutes navigating traps, huge vault doors, combination locks etc etc... then finally at the last one it won't let him in, so he walks 10 feet down the hall to another door and walks right in.
Secure apps are worthless without a secure OS to run them.
I work for the Department of Redundancy Department.
You can use the best building materials available to modern man, sparing no expense, but your construction will never be as stable as it could be if you're building on swampland.
Windows is swampland.
occultae nullus est respectus musicae - originally a Greek proverb
was "I do the VeeBee." ...which is almost half a step up from "I'm an HTML programmer".
I find that listing MS certs on a resume is a wonderful timesaver. Any resume I get that leads with MS Certified [whatever] is swiftly disposed of, into a strong metal container.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
When the leader of the Free S/WAN project went up to MS to do some interoperability testing, the first thing he asked was: "Ok, what crypto protocols have you implemented that we can test?" They told him "40-bit DES". That was all. Once he realize that they were serious, he just left.
To MS, "Security" is nothing more than a checkbox on a feature list. They don't care about your data security, and they really don't have the skill to help you if they did care.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Most of the techniques mentioned are still useful (if you're a .net lamor), but a lot of information is outdated.
How can something be useful and outdated? If outdated, to me, means that something has lived past it's usefulness.
Dedicated Cthulhu Cultist since 4523 BC.
step 1:
format c:
step 2:
insert *nix install disk
step 3:
install (this probably makes step 1 pointless, but we're talking security, better safe...)
-Tim Louden
Christ man all the moderators must be windows admins tonight. Seems like every crack at windows is being modded down. You know what...screw you moderators I bless this poster with...well my make believe funny moderation
Nah Nah na boo boo!
what?
slashdot has become my #1 source for good Windows development ideas.
.NET to the front page. :-)
I think it's actually funny considering a few years ago they were afraid to post an announcement about release of
>>If the underlaying closed source API has bugs there's nothing much you can do about it.
>Does this mean that any system with bugs is not worth developing for?
Is that a strawman I sense? The statement clearly points out a quasi-fact. That is, closed source is not modifiable. Of course, you can modify closed source. It's just generally very difficult. So, a better, valid question is "is it fair to choose which system to develop on based on the ease of fixing bugs?". Of course, it's also a valid (but somewhat unrelated) question to ask "is it fair to choose a system based on the number of bugs?". In the long-term, the former question is more important than the latter.
>And if this is true does it mean that developers who code third party software should be absolved of any wrong doing?
I'm really not sure how you're making such a connection to the original connection. By this, I mean I don't understand how being concerned about bugs in the system would somehow make one not concerned, let alone remove culpability, simply based on who developed software. If you're trying to point out that the original poster probably believes that all code should be open, as that's the only way to make it easy to fix bugs (though obfuscated code doesn't make open source a panacea), then I can somewhat see a connection.
>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.
Of course. But even if AOL didn't have a lot of "retards" working for them, they're still stuck developing for a system that puts them at the mercy of closed source system software--they're stuck, btw, because the majority of their market is composed of Windows users, and trying to force users to switch to another OS to use your software has been historically a dead-end.
>If we hold ourselves to only the highest acheivements of the worst developers we're all going to be in trouble.
For our own development, of course. But the highest development of any developer cannot outweigh the flaws of the underlying system. One can only work their best to try to mitigate the damage.
>And what of those that have to use Windows? You may sit high and mighty and laugh about this but some of us are paid to code for Windows. Are we suppose to go find all those Linux jobs that I keep hearing of just because MS writes bad code?
No, but it helps to recognize that no matter what you do, your code won't fix problems in MS's code.
>That's like quiting a company after finding that a CEO high up embezzeled (sp??) funds.
Well, this seems quite out there. Recognizing that Windows is flawed fundamentally in various ways means learning to accept it. A better analogy would be if a CEO high up embezzled funds, but instead of accepting it and trying to deal with it--after all, one crummy CEO doesn't make a bad company--instead going on and on about how it was all some big misunderstanding and talking about how lots of people take money that isn't theirs. Denial doesn't fix problems. Neither does running away. Coming to terms with the fact that one doesn't have full control over their system, short of a lot of hard work, might comfort you. Or it could be just like accepting that you're going to die some day. There's always religion, right?
PS - With things like closed source BIOSs, various firmware, and hardware one probably didn't construct themselves, it's not like GNU/Linux users are in some aura of control. Though, I'd claim they're probably in more control of their system.
Eurohacker European paranoia, gun rights, and h
I stand by my initial argument, regardless of the opinions of the moderators.
Stop learning! Only you can prevent esoterrorism.