Application Security 101 – “What Application Security?”
I was stunned when I heard it (though I shouldn’t have been).
I was working on a client site performing a vendor review, trying to understand the control framework that the vendor had put around application security.
I explained to the client that I was looking for controls that had been put in place pertaining to the application development life-cycle — right from design, development, deployment, upgrade, and maintenance — for each of their applications. That’s when I got the response, “what application security?”
As I continued to probe, I was gently eased out to an early lunch. My questions about application security were obviously making people uncomfortable — discomfort I’ve unfortunately seen in many situations.
Application security, when not done right (as in this case), exposes the company to significant risk. Applications are assets, assets that provide the highest value.
Applications capture enterprise value and weave it into a business process that can be executed through people and technology. In essence, within applications, you can locate the beating heart and living soul of what the company does – the value producing machine.
Since applications provide such a solid platform for sustaining value, isn’t it important to ask how they are protected from risks? Is the same asset that is so valuable also cascading larger risks back into the company, if left unprotected?
And shouldn’t budgets be set aside to protect this most valuable of asset classes?
Granted, sometimes companies assess application-related risks and make a careful choice to accept rather than mitigate them (especially in the case of legacy applications), but usually the resoundingly obvious answer to all those questions is – Yes. Yes. Yes.
If (I Don’t Know) It Ain’t Broke, Don’t Fix It
In most corporate environments, applications continue to be the weakest link from a security perspective. When you scratch the surface, you uncover assumptions like these:
- Our applications are secure, and we have no threats against them.
- We know we need to take a look at our applications, but we will start when we have a budget for it.
- We want assess our applications for risk, but our management is not aligned and our people are not trained.
- All our applications are secure because every year our managers sign off on an attestation stating that the applications are secure.
Let’s understand the basis for some of these assumptions.
The first assumption usually occurs in companies that have never had the misfortune to be hit by a breach – or at least one that they know of, or one that has been publicly disclosed, so their approach to application security goes something like this – If it ain’t broke, don’t fix it.
Risk management professionals have a name for this approach – it’s called “head in the sand”.
The second assumption is most commonly made by companies that suspect that they have problems, but don’t want to investigate further because if they do, they might expose a risk issue that they would actually have to deal with. They’re usually overburdened with so many other things that they can’t bear adding more to their To-Do list. Along the path of risk enlightenment, you could say they are one small step ahead of the category above.
The third assumption is made in companies where smart people know there’s a problem with application security, but for a variety of reasons, they don’t have the language or access to convince senior management that application risk needs to be addressed by budgeting for remediation and training.
The fourth assumption is voiced in companies that assign application risk to “application owners”, and that all you have to do is have these “application owners” sign a declaration that the applications are secure. This usually is the only mitigation they offer when asked for evidence of application security. By far, this is the most dangerous situation, since such self-deception fosters a false sense of security.
Does your company make one or more of these Application Security assumptions? Granted, most of these problems reflect very real resourcing, prioritization, and communication challenges, but in this age of targeted threats with state actors, it’s important to make an honest self-appraisal and bring the discussion of application security to the table.
Companies that don’t focus their attention proactively on their applications end up surprised to see new competition come out of the blue offering equal or higher value capabilities, based on intellectual property that probably leaked out . . . from their own applications!
Join the conversation and share your war stories about your challenges with Application Security.
Categories: Application Security Monitoring, Risk Management | Tags: application, application security, risk management, security life cycle | Leave a comment
Podcast: Why Basic Cybercrime Tactics Still Work – Experts Discuss the Recent Wave of Wire Transfer Fraud
In September 2012, the FBI, the FS-ISAC, and the Internet Crime Complaint Center issued an alert about a wave of fraudulent wire transfers impacting many small and mid-size financial services institutions. Subsequent news reports suggested that very large firms were also victims and that overall losses might tally in the millions. The phishing-based tactics used to gain access to employee credentials, however, are not new. In this podcast, CISOs and threat intelligence experts talk about why large and smaller enterprises are still wrestling with well-understood security challenges. Listen to podcast (27 minutes).
Categories: Cyberthreats, Threat Intelligence | Tags: cybercrime, fraud, phishing, security challenges | Leave a comment
Security Pros Need to be Aware that People Perceive Security Risk Information Differently
How do stakeholders process security reports and SIEM output? Do they understand the intent and content of the information or was the information misunderstood? Was the information ignored? Was it considered valuable? Most important, did the information enable a “good” decision and subsequent action? To begin answering such questions, it is worth considering how different stakeholders accurately or inaccurately perceive security risk information.
There is a fair amount of work underway within the domain of risk science – specifically, research targeting the communication of risk information. Effective risk communication is required to avoid squandering risk management efforts, and the study of risk communication seeks to examine and understand how specialists’ communications with non-specialists either enhance or degrade non-specialist decision making ability.
Back in December 2012, panel participants at the Society for Risk Analysis (SRA) Annual Meeting in San Francisco, CA, presented and discussed the interesting topic of “numeracy.” Numeracy is defined as the ability to reason and to apply simple numerical concepts and operations such as addition, subtraction, multiplication, and division. Numeracy can also apply to a person’s proficiency in other areas such as computation, measurement, geometry, probability, and statistics. It is worth noting the presenters’ common theme: we all vary in regard to our numeric abilities, and some of us simply find it easier to process information in a visual manner.
In fact visual communication is another risk communication topic area that contains its own research agenda (to be discussed in another post). All this risk communication work is important because as security professionals, we seek to help target audiences better understand the domain in which their decision will take place and make smart, informed risk decisions in their respective firms’ best interest. So till next time, look inward and reflect upon how numerate you perceive yourself, and how numerate you seem to others!
Categories: Conferences Attended, Risk Management, Security Operations Processes | Tags: numeracy, risk communication, risk management, risk science, security risk information, SIEM | Leave a comment
Vigilant in DarkReading: Chief Scientist, Lance James, weighs in on massive Twitter Breach
[...] Several security monitoring companies, including Vigilant, said they detected the attacks. “Although details of entry have not been made public, based on Vigilant’s threat intelligence monitoring, we have observed that the motivation was to harvest email address for future spam use,” said Lance James, chief scientist at Vigilant, in a statement.
“Multiple emails came through this weekend from victim accounts through bulk mailers, and when contacted, the victims indicated their Twitter account was on the list and that they had also received the email address from their Twitter account,” James said. “When passwords were similar, or the same, the attackers used them as a stepping stone to further access email accounts associated with the hack.” [...] Read entire article
Categories: Hacking / Hacktivism | Leave a comment
Methodology to apply Effort Estimates to SIEM applications (Part I)
Continuing our investigation of the practical applications of Software Engineering with respect to SIEM solutions, we will now examine an approach to the Software Sizing and the Effort Estimation process. The successful application of such a process will allow your organization to better estimate the critical aspects of required effort, meaningful scheduling, and costing of the implementation – key factors that drive the investment and budget of your SOC. To attain this goal, we will follow a sequential process of associations and analogies – the first two in this discussion.
Software Sizing and the Effort Estimation processs
Define the SIEM Program Language
Every SIEM vendor embeds its own unique scripted language that functions within their SIEM tool. Unlike any general-purpose programming languages (C, C++, Java, Perl, C#…), SIEM coding can be categorized as a Domain Specific Language (DSL), dedicated to a particular problem domain (SIEM). For reference, I will refer to the programming language as S-DSL (SIEM DSL).
Although considered a “tiny” language, the S-DSL contains expressions and syntax to perform complex programming tasks and data filtering in a succinct and straightforward manner without the benefit of low-level functions for file system access, inter-process control, and programming libraries. In effect, the nature of DSL is very much oriented towards functional decomposition without any of the abstraction or overhead associated with higher-level, object-oriented, general purpose languages. Also, to my knowledge, there exists no tooling that can “cross-compile” from one vendor’s syntax and semantics to that of another.
Thus, a S-DSL can be modeled as a minimal programming language. While “Turing Complete” (though not meeting ISO standards for a stand-alone language), the S-DSL exists only to capture a series of highly domain-specific actions. This approach is of course focused on a functional decomposition approach to analysis and design, with the understanding that each of the functional blocks that comprise the language statements, in fact, is oriented toward finding, moving or displaying a data element. Specifically, within a DSL statement each “action” (query, report, alert) exists as an independent “thread” of code, thus allowing reuse without the abstractions associated with inheritance or libraries. Use case notation may be employed to model these stand-alone actions, but without the ability to employ concepts associated with typical UML notation.
Categorizing the SIEM Programming Language
The potency of the SIEM language lies within the SIEM application: a self-contained package of “systems-level” software. As a high level programming language, it is capable of interfacing through visual design tools the data manipulation functions which interface with an abstracted layer to access real-time data or data repositories (DBMS). These SIEM tools are designed to encapsulate the development environment to enhance the programmer’s abilities to complete all required coding within one interface, streamlining the definitions, relationships, and IPC. The more robust the SIEM tool, the more integrated and elegant the solution – and subsequently the greater the reduction in programming effort, the time it takes to develop the S-SDL, and cost of software development. As a side note, I will note that the efficacy of each vendor’s tools is subject to debate.
Let’s summarize the key properties of the SIEM language:
- Oriented toward problem-solving and systems engineering
- Allows prototyping and evolutionary development
- Designed for commercial business software
- Supports report generation
- Supports form generation
- Facilitates data documentation for statistical analysis
- Embeds a query language (SQL-ish)
- Provides access to a DBMS
- Provides a visual design tool
- Provides an integration API
Due to the fact that every vendor provides a unique solution set, some or all of these functions may be implemented with different degrees of success. Rather than define a programming language for each SIEM vendor, I would propose attempting to identify another programming language with similar patterns and functionality as a comparable paradigm. This will allow us to leverage existing testing paradigms to accomplish the goal of Size and Effort Measurement. Without a lengthy comparison and contrast, I applied Occam’s razor, and suggest that the most relevant programming language which captures these features and functions is one subset of the DSL: the 4GL (The term fourth-generation programming language).
Thus far, we have made some logical assumptions and relationships necessary to apply comparisons in software modeling. Looking forward, we have laid the groundwork for a discussion on what Methods of Measurement are applicable to 4GL. This will give us the leverage to apply efficient mathematical models to estimate Size (the probable volume of SIEM coding involved) and the requited Effort to implement such a solution.
Categories: SIEM | Tags: 4GL, DSL, effort estimation, SIEM, SOC, software engineering, software sizing | 9 comments