Thursday, April 30, 2009
I will be presenting at a Ruby User Group on the topic of enterprise readiness
Wednesday, April 29, 2009
Open Source DRM
Unemployed IT Professionals in the Northeast
The next meeting for the Hartford chapter of OWASP is on June 10th and addition to our usual great topics on web application security, we will be inviting in recruiters from several large enterprises who will be sharing their current job openings.
This meeting will feature Marcus Ranum, inventor of the first firewall.
This event is 100% free to attend. Subscribe to the mailing list to receive updates on future meetings: http://lists.owasp.org/mailman/listinfo/owasp-hartford
Tuesday, April 28, 2009
Retirement from the Blogosphere: July 4th 2009
Identity Federation and Management
Oracle and Sun had competing technologies in the identity provisioning space as well. Migration between these two tool suites is non-trivial, but if one tool will loose the battle, it will become important to think more about standards such as SPML as an isolation layer vs attempting to deal with even more custom adapters.
The strategy around how identity management evolves in the enterprise is actually a more important conversation than whether Oracle decides to keep products around. I suspect that many within the enterprise have done a horrific job of making their identity management implementations other than tightly coupled. Maybe, we need some discussions in the blogosphere on IdM and looser coupling to enterprise applications...
Monday, April 27, 2009
Did you know that SCRUM increases failure in many large enterprises...
1. Scrum implementation fails because the processes of Scrum are not followed closely enough.
2. Scrum implementation fails because the organization does not adapt Scrum to its own environment/culture/practices.
3. The processes of Scrum are not important; only the values in the Agile Manifesto matter.
Many enterprisey types miss one of the key components of agility which is to release early and often. To the degree that you don't do this, your process is not agile and bound to suffer the same sorts of problems that traditional, plan-driven processes have. It may be that this is a temporary condition as you are just getting used to things, but you need to start releasing soon (and regularly). Remember, working software is the primary measure of progress. Putting documents on sharepoints and other traditional waterfall practices are not releases.
More thoughts on Identity Based Encryption
Next week is the start of what I predict will be one of the most meaningful conferences to occur on the planet. The European Identity Conference will feature the likes of Pat Patterson, Jackson Shaw, Kim Cameron, Luther Martin, David Kearns and other thought leaders all under one roof talking about all things identity related. Anyway, I am sitting here thinking about identity and this reminded me of identity-based encryption.
Identity Based Encryption really isn't about encryption but is more about key management. Encryption is an easier topic on many levels than key management and I believe that IBE attempts to sweep the difficulties associated under the rug. Trying to use identity as the foundation is fraught with problems, because no one has a really good solution to verifying identity in electronic applications, whether on the net or in the physical world. Without a good solution to identity, these IBE schemes fall on their face once you stress the identities they rely on.
Most of the IBE systems discussed in the wild lack the technical thought leadership necessary and simply devolve to "trust the provider", which doesn't scale and doesn't provide real security when you really care about it. The provider endeavors to to establish identity over the network, and then acts as a trusted third party, holding the encryption keys for everyone. Relying on a trusted third party has many known weaknesses.
The problem is that you have to have a way of generating and managing those keys, and that turns out to be hard, because the scheme is only as good as the protection you have on your private key. There are a number of methods for doing this.
ID based encryption attempts to simplify this key management problem by proposing special algorithms that construct private keys from a known public piece of information: say an email address. To do this in a way that still makes it hard to figure out the private side, you need to have a trusted entity who constructs the private key based on some other secret they know. So, to establish your communications with someone who knows your email address. you go to the trusted provider and ask for the private key to be generated. The person you want to communicate with knows what provider you use, and gets a master public key from that provider.
Now, the person you want to send to can then generate the public side from your ID without knowing anything except some master key information from the provider; the key is never transmitted direction.
In other words, it looks like this: Alice wants to send email to Bob that's encrypted. They both trust a provider, Tom.
The thing about these schemes is that it simplifies some key management issues, but only somewhat. You still need to generate the keys, and what's worse, you have to really trust Tom, because he knows everything: he can generate your private key, and encrypt with it, making any message look like it came from you. What this means is that it creates an inherent key escrow scheme; your private key can be found out.
Most of the IBE systems I've seen any technical detail about really devolve to "trust the provider", which doesn't scale and doesn't provide real security when you really care about it. The provider endeavors to to establish identity over the network, and then acts as a trusted third party, holding the encryption keys for everyone. Relying on a trusted third party has many known weaknesses.
Modern cryptography is all about searching for ways to not have to rely on the third party. Web of trust is one approach, the main drawback is that it leaves key management to the end users. The solution is not to make key management more expensive but to reduce the process and practices around it.
Traditional PKI approaches rely on certificate issuers where there is clarity on who the certificate issuers are and are known trusted third parties by all. A few years ago, one of the major issues that all the browsers trusted went bust and was bought out of bankruptcy by a player who wasn't obviously trustworthy, making it clear that the weakness in that scheme is at the root of the certificate chains.
Adventures of an Eternal Optimist
Let's analyze her posting to see if new insights emerge:
- I didn’t purchase a conference pass — frankly, I couldn’t, I have just started a new business, and the fiscal reality involved in that activity forced me to be thrifty.
- Being on the outside, however, taught me that while the tracks were inside, the PEOPLE weren’t always, and that in fact by ditching any illusory pretension to education, taking advantage of the Concordia workshop for which entrance only required an expo pass, walking the expo floor, and attending the parties, I didn’t miss the expensive & time-consuming sessions.
- I am usually the most avid attendee at these things, asking a lot of questions and generally participating enthusiastically (ask anyone).
- I’m sure this doesn’t have you crying in your cheerios at the thought of the loss; but I suggest you examine the trend it represents; it is why you want the movers and the shakers *inside* the conference hall, not outside, as often as possible.
Sunday, April 26, 2009
In order to adopt Agile, do you have to divest team members from their respective skills?
Some developers are excellent at server-side technologies and optimization of heavy-weight data provisioning. Others have invested a large amount of their careers learning GUI technologies and have developed a fundamental understanding of users and usability in an application. Neither skill set is better than the other but they are certainly different.
While agile should encourage developers to learn new skills, many simply get better at becoming mediocre and never master another skill. If you have telecommuters involved, they will get even further blurred as managing remote workers is not a skill that many PMs have in their toolbelt and agile makes it more difficult. PMs can either bury resources where they give preferential treatment to those who manage face time or simply give those not in sight menial tasks that they don't have to track (aka busy work).
While I know that many will have a different perspective, I am curious to hear from those who had different experiences...
European Identity Conference 2009
I attend a lot of conferences but this is the one that I am looking forward to attending the most in 2009. If you will be in attendance and want to hook up, trackback. I hope to meet up with many enterprise architecture practitioners in Europe and hope to trade notes..
Saturday, April 25, 2009
Enterprise Architecture: Quote of the Week
-- Linus Torvalds
Friday, April 24, 2009
Enterprise Architecture: How to guarantee outsourcing failure...
Imagine you are responsible for outsourcing a particular function within in a company... Now, the outsourcing has been going well, but it's time for a contract renewal. Will your employer thank you for simply renewing and keeping things the same, and thus keeping the service running well? Unlikely.
More likely, you'll get your bonus only if you:
- screw your supplier into the ground by demanding a huge reduction in rates (leading to poorer service)
- decide to move the contract to another provider (potentially leading to poorer service
- make some other big change e.g. insourcing.
So, how do we align what's best for our employers while not sacrificing what is best for our wallets?
Thursday, April 23, 2009
Are Europeans smarter than Americans when it comes to outsourcing?
Just as an example of smart outsourcing - if you are a company from Sweden, what would be the right choice for you to outsource to? Naturally, it would be a country like Lithuania or nearby. As the location is pretty close but the price difference is two times.
I wonder why American's let Europeans have such a competitive advantage while we have the ability to pull off an even better deal by outsourcing to Jamaica, Trinidad or other Caribbean islands...
Links for 2009-04-23
Do you agree?
Someone likes the latest Gary McGraw podcast
Increasing productivity when times are tough and you don't have money as a tool is something most executives are clueless about.
This problem can only be solved with Barack Obama style governance. If he can get the CEO of GM fired, then I wonder if firing executives who lose data is the next best idea.
Hopefully folks on my side of town are aware of the don't drink the water scandal.
This is the place where all the cool IT professionals hang out.
Wednesday, April 22, 2009
Enterprise Architecture: CMMi is evil...
How many times in your career have you ran across an enterprise architect who is an employee of a Fortune enterprise where they were advocates of CMMI?
Long procedure documents full of obvious statements are evil, because they distract the reader with trivial details. Therefore nobody will read them more than once, and most people will not read them at all (with the exception of folks doing Indian Outsourcing and others who have zero clue about anything).
Of course one cannot simply state that CMM is evil. Making that statement without an auditable artifact flow is against evil best practice. Please create an Evil Requirements Definition document to be submit to an Evil Review Committee as directed in the Evil Development Life Cycle Manual. Once you have obtained the appropriate signatures of the Evil Personnel, you can begin to prepare and Evil Design Document that must be reviewed not once but at least twice. Once you have completed and Evil Preliminary Design Review and an Evil Critical Design Review and again received the necessary Evil Signatures, you can begin to develop your Evil Statement. Once complete, you will have to submit your Evil Statement to an Evil Independent Test consisting of testers who do not know what Evil is but have read through your Evil Requirements Definition.
Of course, you can be Agile and Evil. Evil is flexible. Feel free to generate your own tailored versions of the thousands of pages of standard Evil Procedures. These will be carefully reviewed by the Evil Process Waiver Committee and rejected after wasting even more time and effort.
Thoughts on the Sun and Oracle
Talking about products all day doesn't get me excited. What does is the possibility that Sun may be afforded the opportunity to fix deficiencies in their culture. I have met many Sun employees whom I thought were bright but otherwise constrained in their ability to do meaningful things like interact with customers in a proper way.
Many Sun employees are on mailing lists and are passionate about blogging but yet never find enough ways to interact with customers on a face-to-face basis. For example, in the Hartford CT area, you can find user groups for developers being run by Microsoft, Oracle and other large vendors. What you won't find is a single event that is ever sponsored by Sun targeted at this demographic.
So, we all know that support via mailing lists is a great characteristic but this usually matters only until after you become a customer. Sun simply doesn't do enough before you are one. Likewise, folks understand that I am passionate about building security in and believe that software companies need to have static analysis tools in their portfolio to provide secure code review capabilities. If you were to take a look at the top ten enterprise software vendors, Sun is the only vendor to not have any deep capabilities to review their own code. At some level, they rely on smart people but this isn't a sustainable model.
Oracle's culture doesn't suffer from any of the above deficiencies and if they get the acquisition right, it could be 1 + 1 = 11. Now for a few predictions:
1. Oracle will dump OpenSSO in three years and stick with OIF.
2. Oracle will keep both OIM and Sun IDM as it is too difficult, costly to migrate customers between them.
3. Oracle had a strategy around providing specialized storage capability for Oracle databases. This strategy can now be flushed as they were working with HP on it.
4. Sun employees would do themselves a big favor by being proactive and pursuing their own startups. Think about writing those business plans you dreamed about and getting funding for them. The bloodbath is imminent.
5. The employees within Sun who will survive will not only be the better engineers, but the ones who understand the mindset of those within large enterprises. I suggest Sun employees start reading enterprise architecture books in their spare time.
6. The biggest bloodbath will occur with Sun employees in India...
Tuesday, April 21, 2009
If your wife were a relational database...
looks=gorgeous AND idealman LIKE 'James'
SELECT husband FROM men WHERE
job=geek AND loves=Sherry
Monday, April 20, 2009
Enterprise Architecture: Why inhouse applications are difficult to maintain...
Commercial software development has an advantage over inhouse developed applications along the lines of the ability to maintain conceptual integrity. Requirements are normalized across many different demographics where inhouse developed applications are not.
Within enterprise applications, business rules are often determined by high-level managers and the marketing department. There may not be any apparent logical or rational to many of them from the developer's perspective and asking for it may not be an option. Marketers tend to be "intuitive" thinkers which often drives analytical geeks nuts.
Inhouse applications unlike commercial software have encoded within them, the personality(s) rather than physical or mathematical truths. Enterprise architects struggle to rationalize and devise roadmaps where predicting the future of them gets more difficult as time passes.
Sunday, April 19, 2009
Agile Manifesto 2.0
- Accept the reality of change and embrace it rather than resist it
- Personal responsibility beats external control
- Structure is essential to success, but heavy bureaucracy is not
- Software development should occur via empirical process control rather than defined process control
- Planning is everything, but the plan is simply the starting point
- Perception management is important, treating others like they are human and rewarding them for their dedication and integrity is more important
Saturday, April 18, 2009
Enterprise Architecture, SCRUM and Agile Ceremonies
I was talking to an architect down the road and realized that the buzzword of SCRUM is the latest word to be abused in large enterprises. When folks are talking about SCRUM, they are talking about socialization constructs and not necessarily management practices. All of the agile methods advocate the principle that everything is important but something is more important yet most enterprise architects have no framework that guides them in this regard.
The interesting observation I have noted is that the enterprise architects that still dabble in code have a fundamentally different perspective on the enterprise version of SCRUM than those who no longer code. One can find the results of enterprise SCRUM processes to feel a lot like cowboy coding where folks downstream are
SCRUM is also used to hold enterprise participants hostage. Getting off a project that you didn't much care for to work on something fun, only to be repeatedly dragged back for firefighting is amplified since it requires co-location. The enterprise decision making process has always been sporadic but enterprise scrum makes this even worse. I bet you may have noticed that many of the technical decisions in enterprise scrum are made by the least technical person...
Friday, April 17, 2009
Enterprise Architecture: Are hybrid approaches always useful?
The notion of conceptual integrity is a lost concept in most minds of enterprise architecture where consensus rules the day. We so often compromise on core principles and then wonder why things go awry down the road.
Can the enterprise be truly competitive if decisions are made on facts and logic where perception management is more important? Lately I have been brainstorming PCI compliance and believe that the best way to comply may be to create a company policy that states all servers in the datacenter will be immediately turned off upon the arrival of auditors.
I bet you didn't know that PCI/DSS requires code review as part of its process but doesn't require its auditors to even know how to code? Even if this requirement were put there, PCI only spends an entire fifteen minutes teaching its auditors how to look for worst practices.
This reminds me that I need to bullshit a few process weenies I know and convince them I did a proper code review. Maybe I can ask my seven and four year old sons to bless my code just before heading out the door to Chuck E. Cheeses. I bet they will be real thorough...
Thursday, April 16, 2009
Team OWASP on Kiva
Check out the OWASP lending team, and learn more about lending teams on Kiva in general, by clicking here.
I haven't had anyone yet join from Gartner, IBM or EMC...
Wednesday, April 15, 2009
Enterprise Architecture: You are NOT management material...
Tuesday, April 14, 2009
Enterprise Architecture: When good people get fired...
Recently, I have heard many people talk about being fired. Some feel that the modern approach to management differs from being human (at some level I agree) but also without acknowledging all of the factors that go into a firing decision. So, I decided to outline some things to noodle.
- Employers don't want to pay the cost associated with replacing employees, but eliminating employees is usually considered to be a cost-saving measure. This is why you see competent people let go while incompetent ones remain. All depends on deployment.
- People are not fired only for incompetence or low productivity. Employers fire people for a lot of reasons: economic conditions, cancellation of a project, elimination of part of the organization, changes in marketing strategy, personality conflicts, managerial whims, etc. Employers have the same right to be stupid that everyone else has and may fire their best people when they are needed most.
- firing can be based on trivial factors, such as a single unauthorized telephone call, being five minutes late one day, number of lines of code written in the past week, etc.
Because employees cannot count on their jobs being around forever, employees need to take control of their careers and their economic security. If you save your money, keep your skills up to date, and maintain contacts outside your company, then being fired should not be a disaster. Don't become too economically dependent upon your employer, and don't let your self-esteem or sense of well-being be too closely connected to your job...
Monday, April 13, 2009
Enterprise Architecture and the Federal Government
OWASP Hartford: April 2009
Sunday, April 12, 2009
Time to make it short...
I have made this blog entry longer than usual because I lack the time to make it shorter.
Saturday, April 11, 2009
How low quality is the software your enterprise writes?
So, if quality can be lower in enterprise inhouse software, then that allows for lower-quality resources from Indian outsourcing firms to maintain it. Remember that good is good enough and it doesn't make sense for architects to expend such energy churning on better ways of developing higher quality working software.
Indian outsourcing has caused many to lower their standards and therefore the opportunity to abuse is rampant. Methodologies such as extreme programming encourage merciless refactoring while indian outsourcing has taught us that refactoring is nothing but overhead as you have to write comprehensive documentation in order to get working software. Sometimes the effort but into documentation makes refactoring a non-starter.
Refactoring in code isn't overhead, any more than writing a first draft is overhead in writing a book. It's an inherent part of one of the best ways of producing good code, just as writing drafts is an inherent part of one of the best ways of producing a good book.
American IT professionals have lost the battle because they argued the quality front which no longer matters...
Friday, April 10, 2009
Industry Analysts and Federated Identity
Explaining Security to Business People
Not invented here is a common attitude in many enterprises when it comes to many things but security is even more challenging in that it requires others to acknowledge that their thinking is incomplete and adhoc schemes are not enough before they are willing to spend time and effort to quantify additional requirements.
Security is a business issue and many decisions should be made by business people, however there is no framework that helps business people who generally aren't as passionate as IT in seeking enlightenment to participate and make informed decisions. Imagine what would happen if business customers came up with their own scheme to implement either disaster recovery and/or high availability? They will probably come up with ways that are either expensive and ineffective, or simple and ineffective. There are many ways to handle HA/DR requirements but usually you have to specify the need before you can decide how to do it.
So, what are security professionals not doing that HA/DR types have figured out? Maybe this can be a conversation at an upcoming OWASP conference?
Thursday, April 09, 2009
Are you married to Enterprise Architecture?
You have a certain realtionship with your employer. You also have a relationship with your lover, your children, and your future. When the interests of these parties conflict, this may manifest itself as dissent within one or several of your relationships. Sometimes we are all consumers of a slow poison that is toxic to everything we do.
So, if enterprise architecture is about people, processes then tools, in that order then how do we determine when we should marry things together and when things should be separated. So, if we were to focus on the people aspects then it would probably mean that we need to focus on poor people management which spreads without conscious effort and can slowly poison others.
Poor managers are poor managers for a reason: fear, distrust, ignorance, etc. Over time, they will actually make decisions that increase these qualities in other people they deal with. This is apparent in most interactions with coworkers, but is exceptionally apparent in personnel decisions, with poor managers hiring, promoting, and otherwise rewarding subordinates with dysfunctions that complement their own. The classic example is trusting only a "yes-man", who will agree with every decision you make regardless of the quality of the decision itself.
In addition to rewarding and spreading mismanagement, this will also drive out motivated, conscientious intelligent workers, who will at some point realize it makes more sense to focus on organizational change management over committing to other business-oriented strategies. Through this phenomena, an organization can actually get less competent over time, even with other inputs (size, revenue, business climate, etc.) remaining constant.
Mismanagement can destroy an entire organization, but it can happen so slowly that the managers might not notice it or are likely to misunderstand why the organization is failing. So the feedback loop is not very tight, and they can either avert their gaze from the growing problem or they can find scape goats.