- HP buys EDS for $13.9 billion
- 10 ways the Chinese Internet is different
- What EDS is telling its people about HP deal
- Sprint loses nearly 1.1 million customers
- Desktops of the future here today
Migrating to a new messaging system is a tedious, complex and risky process. And since this isn’t something you do everyday, you need to know "best practices" to ensure a successful migration.
Get the latest on storage technologies that allow IT professionals to better cope with new IT demands. Learn how storage technologies can help you successfully tackle e-Discover, regulatory compliance, green data center initiatives and the data explosion. Get all the details now.
HP's Network Lifestyle Management can help you automate network processes and improve NOC efficiency. This webinar is part three of a four part series on Business Services Management (BSM) evolution to help you better align IT with business objectives. Register for this on-demand webcast now.
Software security guru Gary McGraw is back with a new book, Software Security: Building Security In,which is the third in a series and described as a practitioner's handbook. Network World Editor-in-Chief John Dix caught up with McGraw to talk about the book, the state of software security and the approaches he recommends for doing it better. (McGraw was interviewed in 2004 about his book Exploiting Software: How to Break Code.)
You organize your new book, in part, around what you call touchpoints. What's that all about?
One of the things you need to know about software developers is they have different religions when it comes to their methodology. So there will be people who do something called extreme programming, and people who do the Capability Maturity Model, people who do Spiral Model. And when you go to a developer and say, 'Let's talk about how you develop software,' they're always excited about their own methodology. So the last thing I wanted to do was invent another methodology.
So the idea behind the touchpoints is to create some lightweight security best practices that can be used no matter what your methodology religion is.
The idea came about because I was thinking: What do all these software methodologies have in common? They have in common a set of artifacts. Code is an artifact that you create when you're making software. Or architecture documentation, or test plans and test results. So these artifacts are produced no matter which methodology you're following.
And the touchpoints are about each artifact. There's a picture in the book that shows how the touchpoints align with the artifacts. So the artifacts along the bottom are things like architecture and design, test plans, code, test results and feedback from the field. Those are the things you pile up when you're building software.
And once you have those, you can talk about particular best practices. With code, for example, I can do code review using a static-analysis tool to look for bugs. Given architecture, I can do risk analysis.