Enterprise Architecture: From Incite comes Insight...

Having sat on both sides of the table, I have observed a pattern of missteps that many enterprise CIOs continually repeat. At the top of my list is the mistake in not paying attention to the vendor’s cost of sales…


If a CIO became more aware of their own behaviors and how it can increase the cost to the vendors that serve them, then they can make their own enterprise agendas more successful. First and foremost, it is vital to acknowledge that the enterprise at hand isn’t the only business that needs to reduce costs. This is a trend that applies to be enterprises and vendors alike. If your vendor is a consulting and you require them to hold dozens of meetings onsite where they have to incur travel costs, you will ultimately pay for this cost in terms of increased consulting rates.

A consulting firm measures their profitability in a variety of ways, but one measure to focus on is margin. Every vendor has an established guideline for target margins for each account. Think of the game whack-a-mole. If you increase the cost of sales something will popup elsewhere. A vendor has a few levers to play with. They could propose to conduct business via webinars and reduce costs which serve the enterprise in a way that doesn’t compromise integrity nor causes overall costs to rise. This could of course require the enterprise to focus less on facetime and focus more on outcome.

A vendor could also humor your need for facetime and incur whatever costs are necessarily to satisfy the enterprise need for facetime and pass it along in either the form of increased rates or by providing a junior resource and billing them as if they are an intermediate resource. Generally speaking, enterprises who complain about quality of resources, frequent turnover of staff and changing points of contact tend to be blissfully ignorant to the fact that they may be the cause.

The scenario I outlined above doesn’t just apply to sales facing roles. In fact, it could be manifested in other areas of interaction. Consider the scenarios where you have asked the vendor to create special invoicing, status reports or other clerical/administrative-level activities that aren’t either standard and/or 100% reusable across their other accounts.


If your vendor is more focused on software the challenge of cost of sales exists even more but in manifested in a different manner.  Are you guilty of making proof of concepts (POC) way too long or in squeezing every cent out of a deal at procurement time? The former is somewhat more obvious in terms of the cost it brings, but the later at times can actually be more sinister.

Have you ever heard of a cheap lawyer? I haven’t. Every time you want to change some otherwise minor sentence, it is almost always guaranteed to have to be reviewed by a lawyer. Lawyers really aren’t outcome-oriented and usually only focus on the practice of law. They have a unique way of wasting lots of time discussing the nuances of every sentence. Think about how simple it is for a developer to write Hello World and then switch to thinking how would two lawyers think about putting a contract around it.
Taking this one step further. Most sales teams are coin-operated. In other words, you have to compensate them for each and every activity in some way. The longer it takes for a deal to close, the likelihood of them staying focused on your unique needs decreases. Even when they are assured that a deal will close regardless of how long it takes, they still have to spend time internally to their own organizations churning about it. This creates stress and we all know that there is no ROI in the cost of stress…

The notion of a core competency requires that leaders think much more carefully about which of the enterprise's activities either create unique value as executed internally or which activities that could be more effectively executed by external parties. In my observation of large enterprises in the financial services vertical, I have observed true core competencies being comprised of:

Skill or knowledge sets, not products or functions: Executives need to look beyond the products the enterprise produces and focus on the intellectual skills and management systems that actually create a sustainable competitive edge. Products, even those with valuable legal protection, can be too easily back-engineered, duplicated or replaced by substitutes so intellectual property designation is not a proper filter.

Flexible long-term platforms: Let's be real for a minute. You can really call anything performed by IT as a core competency especially when it is not capable of adaptation or evolution. Focusing on narrow skills which they currently excel such as product-oriented skills is truly core. The real challenge is to consciously build dominating skills in areas that the business and their customers will continue to value over time. This isn't achieved by protecting employees with narrow skills but amplifying those within the enterprise that have flexible skill sets that are capable of tuning and adjusting accordingly.

Limited in number. Are you aware of the fact that Nike outsources almost 100% of the manufacturing of sneakers? They only focus on a few things that truly matter. Care to guess whether they are product focused or more interested in maturing their supply chain?

Intellectual leadership. Many companies are too quickly to label its rock stars as being academic in approach. Knowledge-based core competencies become even harder to overtake as knowledge bases tend to grow expoentially in value with investment and experience.

This is part five of a seven part analysis of Liferay Portal and its security model. I previously covered authentication, authorization, services and automation. Today, I will focus on the problem space of how Liferay handles passwords...





User Passwords
If you haven't been asleep over the last few months, you may have heard about the scenario of many users of LinkedIn having their passwords compromised. The anatomy of the vulnerability had to do with how LinkedIn stored passwords where the algorithm used to hash them was discovered along with the salt value.

Liferay too is vulnerability to the same thing occurring in that there is no administrative process that mandates every unique installation of Liferay either have a unique salt or even requests having one at all. Think about it for a moment, while I can't simply download a copy of LinkedIn and run it on my laptop, I can download a copy of Liferay Portal and generate many of the same passwords as some other user of Liferay.

System Passwords
It is a security best practice to make sure that user passwords are hashed using a one-way algorithm and not stored in a manner that is either cleartext or uses a form of reversible encryption. This however is not always possible for passwords that are used by systems. For example, if you want Liferay to bind to say Active Directory then the password needs to be stored in a reversible form.

Liferay currently stores many passwords in the liferay.properties file in a cleartext manner. This of course would be deemed as non-compliance for applications that need to comply with PCI/DSS. A better way would be for Liferay to create a utility that allows a user to change all passwords to an encyrpted form where the key used to encrypt/decrypt is passed in as a command-line parameter. Of course, someone may also decide to put the password in a command file that starts Liferay, but this at least doesn't make it Liferay's specific problem.

Alternatively, it is a best practice to store keys in a keystore. Java provides a keystore implementation which is callable via Liferay. For Liferay deployments that run on Microsoft Windows, you can also externalize keys to the Windows Keystore as an alternative pluggable/configurable implementation...

This is part four of a seven part analysis of Liferay Portal and its security model. I previously covered authentication, authorization and services. Today, I will focus on the problem space of automation...




The most popular method of preventing automation attacks in many web sites is to leverage a Completely Automated Public Turing test to tell Computers and Humans Apart otherwise known as CAPTCHA. Liferay provides the ability to raise a CAPTCHA challenge at registration time, but doesn't provide any additional configurable opportunities to leverage this mechanism in other parts of the portal lifecycle.

One could envision that at some level, the notion of a CAPTCHA could be incorporated into authorization where it may be useful to know that a given identity is actually controlled by a human and not automation. This is especially useful if the access is via the portal and not the services interface. Another usage scenario would be to require CAPTCHA for all administrative access that occurs from non-trusted IP addresses.

It is important to note that over time CAPTCHA as a mechanism is getting weaker. It's common knowledge that Captchas are fundamentally unable to fully guarantee application security, but they do protect against certain threats. Currently, using tools such as DeCaptcha, attackers can gain anywhere up to 70% automation success in breaking many forms of Captcha so alternative mechanisms are needed.

Insufficient Anti-automation occurs when a web application permits an attacker to automate a process that was originally designed to be performed only in a manual fashion, i.e. by a human web user.

Web application functionality that is often a target for automation attacks may include (comments in Red):

• Application login forms – attackers may automate brute force login requests in an attempt to guess user credentials (Limited to account lockout. No ability to throttle requests or to automate blocking of IP address/range)
• Service registration forms – attackers may automatically create thousands of new accounts (Same as above)
• Email forms – attackers may exploit email forms as spam relays or for flooding a certain user’s mailbox (Same as above)
• Account maintenance – attackers may perform mass DoS against an application, by flooding it with numerous requests to disable or delete user accounts
• Account information forms – attackers may perform mass attempts to harvest user personal information from a web application (Roles provide some protection)
• Comment forms / Content Submission forms – these may be used for spamming blogs, web forums and web bulletin boards by automatically submitting contents such as spam or even web-based malware (only protection is moderation)
• Forms tied to SQL database queries - these may be exploited in order to perform a denial of service attack against the application. The attack is performed by sending numerous heavy SQL queries in a short period of time, hence denying real users from service.
• eShopping / eCommerce - eShopping and eCommerce applications that do not enforce human-only buyers, can be exploited in order to buy preferred items in large amounts, such as sporting events tickets. These are later sold by scalpers for higher prices. (Shopping cart portlet does not adequately protect this scenario)
• Online polls - polls and other types of online voting systems can be automatically subverted in favor of a certain choice.
• Web-based SMS message sending - attackers may exploit SMS message sending systems in order to spam mobile phone users (No ability to throttle or configure a quota)

Anyway, I hope that the Liferay community will consider making improvements in this regard. The next topic will be a security analysis of passwords and other misc functionality...