Improving the Procurement Process

Improving the Procurement Process

I see a lot of RFPs. That’s a good thing in my business, and we are excited to respond to them and participate in the opportunity. While working on an RFP recently, I realized that there was a surprising lack of questions across the board about security and on SSO and Access Management. There were questions about what supported protocols, application integration, architectures, hardware recommendations, etc., but nothing focusing what the system does in action. For example, when a user logs in, and the company is then responsible for their session, how secure is that session?

Really, there is little point of doing a multi-factor authentication system that includes risk analysis, if once the user is authenticated a simple XSS or other attack can trick the browser into passing session cookies to an attacker, which the attacker can just replay.

I am surprised that I don’t see more questions about what the solution does to defeat these possible attacks including timeouts, http_only, cookie domain settings and various other settings to secure the session after authentication.  I almost never see questions asking about alternative session schemes other than cookies. More “what if” or “how” questions could help improve the procurement process by adding more real-world data that would help separate “the men from the boys.”

I believe that we should all begin to focus on the security of our session management software in more detail. What do you think?  Why does it appear we are no longer focused on the fundamentals of security and instead are too interested in playing buzzword bingo inside of a RFP? I have even come across instances where it was suggested that the best technique for timeout security was to make sure the device the user is using for authentication locks itself after a specific time (a response I find both laughable and scary at the same time.).

Without asking the question of session security in the procurement process, a key security capability in the solution could easily be missed.

The following two tabs change content below.

Aaron Berman

Aaron is a security evangelist particularly focused on the areas of Single Sign-On and Directory.  He has spent most of his career helping customers devise a security strategy that enables their business by using identity and access management solutions to protect and secure corporate assets and customer information. An expert in CA SiteMinder and the CA SiteMinder family of solutions, Aaron has assisted customers with some of the largest and most strategic implementations serving hundreds of millions of users.

This article has 3 comments

  1. Nice article Aaron,

    It got me thinking, because I’m always interested in understanding some of the philosophies behind the RFP process and how vendors (in general, CA in specific) can be better partners with those prospects using an RFP process to make a decision.

    I think there are reasons why some RFP’s contain a lot of jargon & acronyms:
    1. They always have, it’s just how they work. The limits of language and the way the people writing RFP’s communicate up their internal value chain sort of make lingo an easy alternative (whereas IMO a better path would be to forgo the RFP, because I’m not sure there’s an easy way to fix the RFP process).
    2. As business is able to make their own IT decisions using cloud and service provider solutions, you’re seeing less technical people participate in the RFP. Or, people who might be expert in one area have to juggle multiple roles and are not expert in security.

    I wrote my own post about fixing the RFP process almost 3 1/2 years ago. Unfortunately, it’s still very relevant.

    VP Financial Services Solutions
    CA Technologies

Leave a Reply