Slashdot Mirror
IEEE Guides Software Architects Toward Secure Design
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.
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.
take your head outa your ass for a few minutes, not everything is republican and democrat here. This has NOTHING To do with politics. we are all dumber for having listened to you, I award you no points, and may god have mercy on your soul
have you seen my sig? there are many others like it but none that are the same
It took me a while to parse your comment... as the IEEE is an international standards body. Then I realized that you weren't talking about nation states, but half of the party system in the US... and then was lost again figuring out how a standards body pushing a security standard for SAs related to political gerrymandering in the US. Did you mean that the Republican party of the US is intentionally trying to make the Internet less secure, and that an international standards body setting down guidelines for big business to follow when architecting new software designs would somehow annoy them because somehow people would suddenly be required to use such standards to develop software like SSL/LTSP/SSH/etc?
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.
Your article written on the flaws in the software architect analogy is a good read, but the role of software architect I am used to seems to be far different than the one you are referring to. When I think of a software or systems architect, I am not thinking of someone who is writing or usually even designing software. They are more often determining how different software systems and business processes are interacting with each other. In most situations, each of these software systems is a black box to the architect. The only software code the architect is usually responsible for is any custom middle-ware products needed to help each system interface with each other.
In this context, many of the critiques you mentioned in your 2003 article are not as valid. Systems architectures are not easily duplicated for different companies, just like a building cannot be easily duplicated. And when working with software products that are often black boxes, the software architect will likely be just as constrained as a construction architect (although usually not by as many regulations and codes).
Obviously there are strong differences between the fields, but there are strong differences between mechanical / electrical / chemical engineers as well. And just as the word engineer has evolved from someone who builds medieval machines of war, I personally see no problem with the word architect evolving from just someone who designs and supervises the construction of buildings.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
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
Fanboy Status: Apache Flex, C#, Eclipse, KDE, Pirate Party, Ron Paul, Slackware, Windows 7
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.
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".
Where are we going and why are we in a handbasket?
Video game publishers might take this as an excuse to shift to OnLive-style remote video gaming, where the game runs entirely on the server, and the client just sends keypresses and mouse movements and receives video and audio.
I'm not sure how binary code and assets for a proprietary computer program could be watermarked without needing to separately digitally sign each copy.
For small web sites that don't store financial or health information, I don't see how this can be made affordable. Two-factor typically incurs a cost to ship the client device to clients. Even if you as a developer can assume that the end user already has a mobile phone and pays for service, there's still a cost for you to send text messages and a cost for your users to receive them, especially in the United States market where not all plans include unlimited incoming texts.
How is disclosure of such a URL any different from disclosure of a password? One could achieve the same objective by changing the URL periodically.
This is W^X. But to what extent is it advisable to take this principle as far as iOS takes it, where an application can never flip a page from writable to executable? This policy blocks applications from implementing any sort of JIT compilation, which can limit the runtime performance of a domain-specific language.
What's the practical alternative to hard-coding a key without needing to separately digitally sign each copy of a program?
If the owner of a machine isn't sophisticated enough to administer it, who is? The owner of a computing platform might use this as an excuse to implement a walled garden.
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, 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?
Ha! My wife works with systems you likely developed, or at least had to have gone through the CIO's office. You clearly have never had to use any of the systems you created. The CMS, in particular, is one of the worst pieces of corporate software I've ever seen. A big part of her job is pushing files _one_at_a_time_ to the production systems because there is no way to do bulk updates. Rolling back is just as painful if a problem is discovered during a rollout (other groups submit the content and, in theory, have tested it ahead of time). There have been high-profile outages of the main web site due to the way the CMS was "architected". She gets paid a ton of money to do something that should be done in software.
Maybe you worked on the trading platform or other systems, but if the internal systems used for content management are any indication, I'd say you did a terrible job and maybe could have benefited from an architect.
My biggest issue with people who don't like architects is this: they usually have never really had to deal with the consequences of their actions and just assume they did a great job. Of course, most architects have the same problem. Large corporations are excellent at breeding this mentality (I know, because I've had to clean up shit from people who reported to the CIO and completely f'd up agile). You'll note that the problem I'm really highlighting here is that in big corporations, software is usually shit and people are applauded for it anyway, regardless of whether they used agile, waterfall, or nothing at all. Everyone thinks they did a great job because they got paid and promoted and report to important people. How could they be doing anything wrong??? :P
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.
You can. But you need to be aware that 99.9% of people doing PHP or Java or the JVM do not have what it takes to make anything that may see real attacks secure. People that can secure things in this particular problem space are exceedingly rare and exceedingly expensive. One problem is that you cannot use most/all libraries for security critical functions, and may well have to augment the JVM via JNI for secure input validation. Most Java folks are not capable of doing that at all.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.