IEEE Guides Software Architects Toward Secure Design 51
msm1267 writes: The IEEE's Center for Secure Design debuted its first report this week, a guidance for software architects called "Avoiding the Top 10 Software Security Design Flaws." Developing guidance for architects rather than developers was a conscious effort the group made in order to steer the conversation around software security away from exclusively talking about finding bugs toward design-level failures that lead to exploitable security vulnerabilities. The document spells out the 10 common design flaws in a straightforward manner, each with a lengthy explainer of inherent weaknesses in each area and how software designers and architects should take these potential pitfalls into consideration.
Re:I love it when the IEEE... (Score:4, Insightful)
Yeah, you mean that damn "Republican" Bill Clinton who was in office in 1996 when ITAR and EAR resulted in the DOJ going after Phil Zimmerman?
In case you hadn't noticed, Clinton was and is a Democrat, and the President is in charge of the Executive branch agencies.
Re:I love it when the IEEE... (Score:3, Insightful)
Mostly common sense but still good reminders (Score:4, Insightful)
Here it is for anyone who didn't bother to RTFA
1. Earn or Give, but Never Assume, Trust
2. Use an Authentication Mechanism that Cannot be Bypassed or Tampered With
3. Authorize after You Authenticate
4. Strictly Separate Data and Control Instructions, and Never Process Control Instructions Received from Untrusted Sources
5. Define an Approach that Ensures all Data are Explicitly Validated
6. Use Cryptography Correctly
7. Identify Sensitive Data and How They Should Be Handled
8. Always Consider the Users
9. Understand How Integrating External Components Changes Your Attack Surface
10. Be Flexible When Considering Future Changes to Objects and Actors
Re:Fire the Architects (Score:5, Insightful)
I don't have a lot of patience with the profession since it's built on a fatally flawed analogy and all software architects ever do is waste and overhead from a lean perspective.
It *sounds* like you've never worked on a large project then. Fine, fire the architects, but you're still going to need someone to do their job, no matter if you call them the team lead or something else. There needs to be a *technical* person at the top who says "we're marching that way" and here's some stuff we need to keep in mind and do. Some technical person who can push back to the product owner when it's needed and explain in technical gory details when required. That's not the project manager because they're not technical enough; or that's been true for all the projects I've ever worked on.
... the cheapest time to change software is during the planning stage before it's written.
You need someone to can look ahead at the items coming and notice that there are some common things needed, and that if you spend some time up front to fix (a framework, a subsystem, whatever) that it will be cheaper and faster to do that way than to let small bits of code be written and then refactored a hundred times as the sprints slowly come in.
I'm sorry you don't like the construction analogy, but it's very true that the cheapest time to change a building is when you're still at the blueprint stage before it's built
Sure, most product owners owners don't really know where they want to end up, but some things are well known and when you have that knowledge you should use it as soon as possible, no matter what you want to call the roles or the results. Protocols, APIs, security, data models and databases, etc are all things that should be planned as much as possible, not organically grown and refactored. Who does that planning?
My day job right now is dealing with code that had very little upfront planning, very Agile'ish, and the system is a nightmare at times. I'll admit that the source of the problem may be that the devs before me never came back and refactored and cleaned up, but a little more planning would have made much of that unnecessary. That's what an architect brings to the table: some overall planning and technical sense.
Re:Fire the Architects (Score:4, Insightful)
I suspect that most programmers who don't see the need for software architecture work within the confines of already heavily architected frameworks, platforms, and network stacks.
Thus their comments are akin to saying "I don't think we need an architect to help us rearrange the furniture and paint on the walls".
API consistency; negative tests (Score:4, Insightful)
Of course, when the end product is as infinitely malleable as software
Software isn't "infinitely malleable" when it exposes interfaces to anything else. This could be APIs to other software or user interfaces. You have to build on the old interface compatibly, and when you do make a clean break, you need to keep supporting the old interface until others have had a reasonable time to migrate.
The human interface needs a design in order to mesh with the humans in an elegant and consistent fashion, but the code? No. The only purpose of code design is to make the code readable and maintainable, and those are attributes you achieve through test driven development and continual refactoring.
APIs need at least as much consistency as UIs. In fact, I'd argue that APIs need even more consistency because human users are slightly better at adapting to a UI through reflection, that is, figuring out a UI by inspection.
The engineering the IEEE is trying to achieve is accomplished by test-first development
Then take this guide as something to consider when determining when you have enough negative tests [stackoverflow.com], or tests that are expected to succeed by failing.
continual automated testing
If you're using a CAPTCHA as part of a process to authenticate a user, how do you perform automated testing on that?
Re:Fire the Architects (Score:4, Insightful)
I love your claim that you rewrote Charles Schwab from the ground up with no architectural plan in place yet state that you were the chief architect. Your up-front architecture was the old systems you were replacing. You had laid out before you everything that had to be accomplished, what had to talk with what and how as you went through the process of replacing and retiring systems.
Just because you don't want to recognize that as up-front architecture doesn't mean it wasn't there and you didn't do it.
Of course, taken literally, your statement also admits that the whole thing never actually worked: "there was never a moment when all the applications were fully functional." I'll choose to read that combined with the sentence that follows as you did not do the whole rewrite before switching to the new system. That is more evidence that you were using the existing system as an architectural guide to how the system communicated.