Tag Archives: CIO

WHY APPSEC (APPLICATION SECURITY) WON’T ALWAYS BAIL YOU OUT OF APPLICATION BASED RISKS?

Posted on by
Reply

WHY APPSEC (APPLICATION SECURITY) WON’T ALWAYS BAIL YOU OUT OF APPLICATION BASED RISKS?

It is very typical of organizations to perform Web Application (WebApp) Security Assessments before the go-live of newer applications or periodic assessments of their existing applications. And these assessments are known by all sorts of aliases like Application Penetration Testing (App PenTest), Ethical Application Hacking etc. For those companies lacking the internal core competency of AppSec, often outsource this activity to competent 3rd party players in the market.

What does the CxO function expect post an AppSec assessment?

This (the AppSec assessment) is often treated as an additional or ancillary investment to the core development expenditure. The CxO function expects air-tight security within the application after such an assessment. Once the development teams start mitigating actions; one can often hear statements filled with hyper-expectations like ‘the application should now become un-hackable’ or ‘no one break the application now & it can go public’.
So why are AppSec tested applications still not secure?
In most of the cases applications undergo assessments when they are either almost ready for production or already in production. This is against the spirit of AppSec to begin with, as AppSec is a process should ideally be invoked right at the inception of the applications SDLC (software development life cycle). Very rarely are AppSec resources involved during the requirement analysis or the finalization of the design. And therefore the assessment that happens (post development) is more of a corrective activity rather than a proactive one. Flaws and vulnerabilities that could have been killed right at the beginning; are most often patched (with quick hacks & not actual AppSec best practices) after the application is already in production.
AppSec professionals are often expected to perform miracles & mitigate flaws that are often connected with the lifelines of the application. While business pressure will always compel the teams to have applications up & running; it is never an easy situation for any CISO to let such applications fly without the proper checks and balances. Here are a few crucial factors that every CISO needs to consider before signing-off applications & eliminating the blind reliance on AppSec assessments. Although AppSec assessments are vital they can never address the people, processes & technology completely.
• Lack of STP (Straight-Through-Processing) & Manual Hand-offs
AppSec can never be held responsible processes that are offline or that are performed manually. While AppSec testers can test for data validation; they can never test for business rules. It is a common practice in several organizations, to have online workflows that detach themselves into (smaller or multiple) manual tasks. These could include physical verification / inspection, offline approvals or matching records with another system. Whenever there is manual hand-off; the application has to rely on the validation of the incoming data. This data can never be tested AppSec resources. This is simply because Applications only control the use of resources granted to them, and not which resources are granted to them.
• Intentional disruption of maker-checker mechanism
One of the most observed practice with corporate is the dissolution of the maker-checker mechanism in the name of ease of use & time-saving. While such business rules may save some time; this is definitely the worst practice to adopt. A typical request-approval workflow works on the basis of the requestor (the maker) posting a request & some approver (checker) taking a decision to approve, reject or hold the request. This workflow is generally disrupted by adding functionalities like the ‘checker being able to modify the request’ or the ‘checker being able to delete the request’. In such a scenario no there is no validation or approval on the action taken by the checker & the very essence of the maker-checker mechanism is lost. AppSec can only detect flaws (if any) in the transfer of control from the maker to the checker; But it can never challenge the business rules or the excess privileges assigned to the checker.
• Password Management
Auditing for password management is always a tricky situation for AppSec professionals. While AppSec can always verify password strength, secure password storage & transmission. AppSec not dictate terms on the hard-coding of passwords into application frameworks. The most commonly found password management lacunae are Hard-coding passwords into macros and stored procedures & using a uniform password across the application framework. Because these passwords are hard-coded & difficult to change application development & infrastructure teams often seeks exceptions to ‘never change the passwords of the target systems or databases’.
Besides this; AppSec can also not address the problem of password sharing among the application development teams.
• Excessive Super-User privilege abuse
Singular administrative user credentials being used by an entire team for local / remote administration like running backup scripts, routine batch jobs or updating and patching, is one the worst enemies of AppSec. While AppSec assessments revolve around the application components residing on the infrastructure; having multiple super user identities or sharing credentials of administrative users completely defeats the purpose of implementing AppSec controls.
Allowing too many user identities to directly access the application backend, makes access auditing very complicated & this also makes change and incident control very challenging. Questions like ‘who did what & when?’ become very difficult to answer. It is therefore extremely essential to audit & restrict unnecessary access on the infrastructure that hosts the application.
• Unauthorized migration of environments
Developers often start development on a sandbox environment (colloquially known as the ‘Dev’ environment). As soon they start progressing on their (software) builds / releases; they often do not port the changes into the UAT (User acceptance testing) or QA (Quality assurance) environments. This is a very common blunder made by many development teams under the pretext of meeting stringent timelines and lack of migration strategy. This causes same build / release to mature on the ‘Dev’ environment itself & the same environment eventually lands up in ‘production mode’.
Before actually starting the AppSec assessment; internal teams must ensure that a clone environment along with the production is ready-at-hand. This decreases the chances of the application becoming unavailable due to unforeseen effects of the assessment. Sometimes the AppSec testers run intrusive checks which have the potential to bring down essential services within the application.
Besides this, a clone QA or UAT environment helps to expedite the vulnerability mitigation process, without any negative business impact.
• Excessive dependency of automated scanning tools & services
Most organizations looking to build-up their internal competency towards AppSec, often procure some sort of automated scanning tool or a service. These services are also offered a pay-as-you-use on-demand cloud service. One of the key aspects here is that these tools or services are completely Black-Box. These tools do NOT have the ability to:
1. Understand business rules & workflows.
2. Detect & Interpret ‘logical’ vulnerabilities.
3. Can perform ‘deep crawling’ in sophisticated applications that do not give all the links.
4. Support for JavaScript & Flash based vulnerabilities.

Most often several of the vulnerabilities reported by these tools are false-positives (and worse; sometimes false-negatives, too). A great amount of human effort is required to fine-tune these scanners. Automated scanning can never replace human AppSec professionals; these tools only help to facilitate the assessment.

Why a NetSec (Network Security) assessment if often better at annihilating WebApps?
This is purely based on my personal experience, after I saw some interesting results, post some internal NetSec assessments. The approach of NetSec professionals is very different from the AppSec folks. NetSec pros rather concentrate on the attack-surface (server infrastructure & communication equipment) than get into the application itself. AppSec & NetSec, both are hot skills in the market and good resources are very hard to find. This is in no way comparison of intellect or level of difficulty of either of the disciplines.
Let me illustrate my point with a simple scenario that highly persuaded me to give equal importance to NetSec, while assessing WebApps – - – When an AppSec tester is able to manually verify a privilege escalation, he/she would generally note down the affected module (piece of the application) & rank this risk based on the data that became visible, as a result of running the test. However; this escalation may not necessarily take him any further and could be dead-end. A flaw – nevertheless; but doesn’t result into someone taking over the complete application.
While the AppSec test will conclude in that manner; NetSec pros take this to the next level. They generally don’t rest until they have struck the application really hard. They will peruse this till they find some serious information leakage, an SQLi (SQL injection) that reveals some fascinating data, or any general platform flaw that lets them ‘own’ the entire system. The key difference that I observed here is that while AppSec folks will generally not venture beyond assessing and testing; NetSec pros take the application environment to its breaking-point. This clearly indicates the distinct ideology of the two skill sets.
The argument here is not that if an assessment is better than full-blown PenTest or not; but that sometimes AppSec professionals get mental blinders & that they should freely consult with their NetSec peers for helping them perform successful PenTests.

 

~Dhananjay Chandrashekhar Rokde

Request for Problems / Pains – The RFP Saga

Posted on by
2

Request for Problems / Pains – The RFP Saga

Organizations are constantly looking to grow organically and inorganically. It is obvious that they cannot sustain by themselves in the massive business eco-system. Every organization at some point MUST rely on another organizations or individuals subject matter expertise & experience to address it requirements in order to ensure its growth. So; with a huge plethora of vendors & experts available; how does one make a choice? Did someone say Request for Proposal (RFP) ???

Here are few basic ingredients that an RFP must contain:

1 Organizational Overview
A brief about your organization & group companies. Should contain details like your primary business expertise, history, Net. Worth, global presence, Employee head-count etc.

2 Target Audience
This should clearly address as to whom this RFP is meant for. You may want to add industry credentials like “Looking for an ISO 9001 vendor”; or look for past implementations like “Vendor organizations who have undertaken large bridge-building projects exceeding INR 150 crore”. You can also add sector-specific details like “Should have worked on multiple government projects concerning micro-finance & credit”.
This section may contain some information of the qualifying criteria as well. You need to use this to filter the audience, so only desired parties subscribe.

3 Required Deliverables (Materials, services, maintenance)
This section needs to contain as much as details as possible of the desired outcome from the overall deliverables, services or materials.
Let use the illustration of space travel and tourism:
“ABC is looking to expand its tourism portfolio and looking to add extra-planetary destinations for its customers. ABC is looking for vendors who can provide expertise, material and maintenance for building a space craft capable of taking passengers and crew safely outside earthly bounds and into nearby planets.”
Maintenance, Post-Delivery details and services like consulting should also be mentioned. “The selected vendor organization will be required to support the ongoing maintenance and repairs of the space craft until 2021. The vendor will also assist in developing in-house expertise within the ABC staff to create sufficient redundancy.”

4 Technical details
This section needs to contain all possible technical details, for the vendors to clearly understand the nitty-gritty’s and challenges. So continuing from the above example; you need to mention details like capability of flying to the moon and back, should run on clean bio-fuels, should have a maximum speed of at least 1000 Km/hr etc.

5 Assumptions and Agreements
Some obvious assumptions may be excused; however all contractual bindings, agreements should be mentioned here.
“The selected vendor will not engage in a similar engagement of extra-planetary travel, until the cessation of the contract in 2021.”

6 Deadlines (Stages & milestones) / Payment Schedule
The entire activity needs to broken down in phases, and each phase should have a clear deadline.
It is very important to clearly define this section as it can be linked to payments in stages. Hence you can keep a track of progress, and also budget the outflow accordingly.
We can break down our earlier example in to these stages, assign desired deadlines and percentage payout of the total project bid- Finalization of design, build prototype, pilot training, crew training, test flight, etc.

7 Overall (Net.) deadline – The project must be completed by ___________.
The ultimate deadline for the vendor to produce the FINAL deliverable mentioned in section 3.

8 Maximum Bid Criteria (Vendor bids may not exceed $150,000.)
Based on your budgets you need to specify the penultimate monetary figure which you are not willing to exceed for the particular activity.
You can also mention a disqualification criteria if any vendors bid exceeds this value.

9 Request for References (optional)
Seeking references is always a good practice in terms of due diligence to seek references from the vendors previous deals/projects.
You may ask to vendors to attach certifications also.

10 Submission Deadline
Deadline for the submission of the RFP with all relevant attachments and annexures.

11 For Additional Information or Clarification, Contact:
Contact information of the bid officer from your organization.
It may be good idea to have multiple contacts in this section.

12 Basis for Award of Contract
The selection criteria must be very clear precise. The criteria maybe lowest bid, most implementation experience, best industry credentials, most subject matter expertise, best 3rd party negotiated prices etc.

13 Award Date
Date of award of the contract.

Additionally you may also want to include sections like:

1 Legal
All Legal bindings on the vendors must be clearly mentioned. Eg: Signing of non-disclosure, non-compete agreements; Applicable laws like trade secret, employee health & safety etc.

2 Penalty Clauses
Should the vendor delay the overall project or delivery, you should have penalty clauses to protect your organization from the occurring financial harm.
The penalty clauses should clear in terms of the amount of deviation and the amount (or percentage) or penalty.
Eg: “The vendor will forfeit an amount INR 10 Lac for every 30 days of delay in the project” or “Should the reliability and efficiency of the space craft drop below 99% at anytime, the vendor will be penalized an amount of INR 50 Lac.”

3 Personnel Clause
Vendors may often look to further outsource the work to other parties or consultants for a small margin. Having a personnel clause in place can protect your organization from these freelance or 3rd parties.
It is a good idea to mention a mandate like; “All vendor personnel must have served in the vendor organization for a period of at least 3 years” or “All personnel deployed by the vendor are subject to scrutiny like reference checks and technical interviews”.

4 Project re-negotiation / modification
It is normal for large projects running over a period of 4-5 years, to deviate from the deadline or budget due to reasons which are beyond the control of your or the vendor organization. To normalize such a loss; you should have a re-negotiation clause to protect the interests of both the parties.

Also here are a few more pointers to keep in mind:

1. Do NOT follow some random template.
a. Any RFP template is just a good starting point
b. What works for someone else, may not always work for you
c. Communicating clear requirements to any vendor reduces almost 30-40% of all future complications. Hence one must send out as much information as possible of the organizations business expectations.

2. Be as descriptive and precise as possible
a. This will reduce the number of follow-ups from the bidding vendors. If you have several interested parties; clarifications and follow up communication could drive a project manager crazy.
b. This also reduces the possibility of an awkward situation due to misunderstandings and discrepancies.

3. Always include information of your existing environment.
a. In this way vendors know what they can and cannot expect from you.
b. For consulting services; it is a must to mention the existing process and the desired ‘to be’ process.

4. Have clear performance & milestone indicators
a. Even the slightest deviation in the project in terms of time or cost, should be visible and highlighted at the earliest.
b. If the payment schedule is performance or milestone based, then the performance metrics or the milestone achievement criteria should be clearly defined.

5. Develop a clear vendor pre-qualification criteria within the RFP
a. This will keep unwanted bidders at bay
b. You will get attention only from deserving parties
c. Have a very crystal clear qualification criteria. eg: instead of mentioning “The potential vendor should have vast experience in space travel”; a clear qualification criteria would be “The vendors must have successfully completed at least 4 space travel projects in the last 10 years”.

Other types of proposal requests:

A request for quotation (RFQ) – An RFQ is used when clearly price is the only winning condition.
A request for information (RFI) – has a greater capacity to gather additional information about the bidder’s capability in terms of delivery of material & services. RFIs should be used for reasonably major procurements. Based on the detailed inputs received from the RFI; the buyer could issue another RFQ / RFT to close the deal.
A request for tender (RFT) is used by public organizations & governments.

The ‘Fear Factor’ in Information Security

Posted on by
1

The ‘Fear Factor’ in Information Security

Why Information Security cannot be implemented off-the-shelf?
Why is Governance is a must have?
Why is there no ‘Silver Bullet’ in Information Security?

Information Security has gained epic importance over the years. Information Systems, regulations and certification bodies have matured overwhelmingly to address information security & its cause. Organizations all over the world have clearly shown dedication towards Information Security which is clearly evident with respect to:
• Increase in Information Security Spending per annum
• Hiring dedicated Information Security professionals
• Segregation of duties for Information Security Teams from routine business operations
• Global increase in the number of certified organizations year-on-year
• Increasing public and employee awareness

However, there are several forces that influence the use and development of information security related technologies, products & services.

1. Research Group Reports – The modern CxO’s bible.

The likes of Gartner & Forrester produce the most influential reports on trends & insights for the CxO to make an informed decision. What in fact happens in most cases is that these research reports are firmly taken as guidelines by senior management and this often misleads them.

What I have personally realized is that as far as Information Security is concerned, the mantra of “If it works for them, then it will work for us” is aptly wrong. There are dozens of initiatives that are pushed from the top, which eventually run into the trash. India has witness huge multi-million dollar projects being scrapped, because the people who authorized the same, didn’t know what they were talking about.

“The report says that this product is better and more secure. What are we waiting for?” – The most common pitfall any senior management can fall for. There are an increasing number of cases where products are replaced, upgraded or integrated with other products for the sake of proving a point. You are not more secure just because you have the best, latest or the most popular products. Several management teams fail to realize that a mere product or technology is NOT good enough to secure your organization.

“Use the data, trends & comparisons of research reports as a supporting guideline and not as the Bible”.

2. The ‘Vendor’ strikes back

One must always keep in mind that every organization and geography is unique with respect to culture, people & technology. Similarly you can never have a one-size fits all approach towards in information security. With the increasing number of technology, product and services options, the modern day information security manager is swamped with a huge number options as far as vendors for a particular technology is concerned. So which one is right for you?

Vendors often cite examples of compromised systems or security lapses to make an up-sell. These information security breaches are often magnified and overblown to accommodate the features of one particular product. And we’ve clearly come a long way since the Heartland Payment Attack. The general tone of any information security vendor is “This could happen to you unless you use a particular product / technology”. Very rarely have I come across a vendor who promotes his/her product in a positive manner and only talks about the products actual advantage. Most vendors will try and score cookie points out of comparison sheets (highlighting the shortcomings) of their rival products. This is also because of natural human tendency of an Information Security to ask “What’ve you got, that they don’t?”.

Yes; vendors are an influential force today. Pushing products into the market & industry does require a unique talent, which I appreciate. However, lately information security vendors are increasingly using the fear factor and coarse tactics to pressure information security managers into deploying rather unnecessary technologies and products. Why have we never heard of a vendor pitch claiming responsibility of failure to protect a company’s infrastructure?

Since DLP & DRM is the talk of the town at the moment; I would like to take an opportunity to highlight these as an example of why off-the-shelf is not always off-the-hook; and leading to why Governance (next point) is still key to ensure success.
Most DLP/DRM vendors promote the fact that by deploying their solution you can achieve SOx, HIPAA, GLBA, etc. compliance. Well; that’s just a fake promise & blatant lie. Also locking down and physically removing DVD-RW’s, USB & Floppy (if, at all) drives does not resolve this issue. Any DLP software is just a mere program and at most can restrict you from printing, editing, revealing data in locked areas etc. Lets now look at what a DLP can NOT do:
• It cannot stop hard copies being physically taken out of your facility
• It cannot prevent you from using mobile camera/scanner software
• It cannot prevent a HDD or a tape from being taken away

Let us now agree that a DLP is not something you can achieve with measly software. It is a humongous initiative that requires strict controls, strong governance & continuing vigilance. If you are still not satisfied; here is an addendum to list of things a DLP can NEVER do for you.
• Implement a clear screen / desk policy
• Implement physical security controls
• Removal of unnecessary rights from administrators & domain owners
• Impose restriction of social media
& so on … Moral of the story – Irrespective of vendor claims; there is no ‘silver bullet’.

3. Governance – Do we really need that? And who’s job is it?

Technology and products once deployed need to be integrated with a company’s DNA for maximum results. Often it is seen that products and technologies are procured and heavily under-utilized or wrongly utilized. There are several reasons for this:
• Insufficient testing & lack of Proof of Concept (PoC)
o It is vital to test not the product features; but how the product will actually address the actual business need. Most PoC’s circle around testing the product itself & never really see how this product will talk to other business components (people, process & technology).
• Multi-function products are procured to address a single business requirement. The remainder of the functions either remain un-configured or are never utilized.
• Personnel attrition
o While this remains an underrated cause of failure; it in fact tops the list. When undertaking any project, an organization typically deploys a project manager and small team behind him to initiate the project.
o However, this team does not stay as-is till the completion of the project. The core team which actually knew the business hurdle and the objective of the project dilutes over a period of time & the cause is lost in thin air.
o This is most often the cause of poor implementations, ineffective security & also causes a tremendous amount of re-work (read cost).
• (Unexplained) Exceptions
o While Information Security often imposes restrictions for its cause, these restrictions are often overridden by the top. This often kills the cause of the project.
o While exceptions are a good thing to have; they really should be treated like ‘exceptions’ and not routine business calls.
• Lack of integration with existing workflows and service management environment
o The new product or technology should accommodate itself into the existing service management environment; and NEVER vice versa.
o The product or technology should never change the way you work; it should always be otherwise.
o Change & impact assessment should be re-done formally despite the fact that you’ve (repeatedly) tested the product.
• Roll back strategy
o Yes! A product can fail. It can fail to meet the business, performance or technical requirement (Despite what its brochure/data sheet says).
o While most project teams always work under the assumption that if it succeeded in the test-bed or in a 30-40% sample environment, it will eventually go all the way.
o There MUST be an exit strategy in place.