Thinkervine

The SANS institute has released an article listing the top 25 most dangeurs programming errors as a preventive action to secure software development, limit cyber crime and provide enterprises with a basis for buying their software.

Most of these errors are still not assessed by programmers which might not be totally aware of the fall-outs of their breaches.

This list of programming errors might be used for the following purposes:

• Software buyers will be able to buy much safer software.
• Programmers will have tools that consistently measure the security of the software they are writing.
• Colleges will be able to teach secure coding more confidently.
• Employers will be able to ensure they have programmers who can write more secure code.

The Top 25 is organized into three high-level categories that contain multiple CWE (Community Weakness Enumeration) entries.

Insecure Interaction Between Components

These weaknesses are related to insecure ways in which data is sent and received between separate components, modules, programs, processes, threads, or systems.

• CWE-20 – Improper Input Validation
• CWE-116 – Improper Encoding or Escaping of Output
• CWE-89 – Failure to Preserve SQL Query Structure (aka ‘SQL Injection’)
• CWE-79 – Failure to Preserve Web Page Structure (aka ‘Cross-site Scripting’)
• CWE-78 – Failure to Preserve OS Command Structure (aka ‘OS Command Injection’)
• CWE-319 – Cleartext Transmission of Sensitive Information
• CWE-352 – Cross-Site Request Forgery (CSRF)
• CWE-362 – Race Condition
• CWE-209 – Error Message Information Leak

Risky Resource Management

The weaknesses in this category are related to ways in which software does not properly manage the creation, usage, transfer, or destruction of important system resources.

• CWE-119 – Failure to Constrain Operations within the Bounds of a Memory Buffer
• CWE-642 – External Control of Critical State Data
• CWE-73 – External Control of File Name or Path
• CWE-426 – Untrusted Search Path
• CWE-94 – Failure to Control Generation of Code (aka ‘Code Injection’)
• CWE-494 – Download of Code Without Integrity Check
• CWE-404 – Improper Resource Shutdown or Release
• CWE-665 – Improper Initialization
• CWE-682 – Incorrect Calculation

Porous Defenses

The weaknesses in this category are related to defensive techniques that are often misused, abused, or just plain ignored.

• CWE-285 – Improper Access Control (Authorization)
• CWE-327 – Use of a Broken or Risky Cryptographic Algorithm
• CWE-259 – Hard-Coded Password
• CWE-732 – Insecure Permission Assignment for Critical Resource
• CWE-330 – Use of Insufficiently Random Values
• CWE-250 – Execution with Unnecessary Privileges
• CWE-602 – Client-Side Enforcement of Server-Side Security

More detailed information on each weakness can be found on the Mitre’s CWE website by following the CWE entry link.

Although most of these might look trivial, many developers do not have a proper security validation process to ensure a robust code for their programs. Sometimes this might be due to delays, sometimes to lazyness or unawareness. Take a good grip for this list and validate that your code conforms to each principle listed in there. You will contribute to a safer cyber world and software continuum.

Anne Thomas Manes published on the Burton Groups’s blog, a SOA obituary. According to her, this is mainly due to the high promises that deceived all CTOs that believed in SOA: more agility, lower costs and shorter project periods.

She also sees the economical context of this coming year as the undertaker of SOA. As these projects are by nature transverse and will go across several business units, the funding of such projects becomes a complex issue: who’s the holder, who’s paying for what. In addition to that, in a reduced budget context, anything non-strategic goes straight to the trash can.

While at the theoretical level, I might agree with part of this vision, we still need to have a deeper look into this to match reality.

Let’s go through a set of questions and analyze it:

1. Why did so many SOA projects fail ?

At the time being, if you ask ten persons what SOA is, you will get 10 different answers. Some will wrongly say web services. Some will call it pure architecture, others will call it methods, others will see it as a combination of the two. A paradigm ?

Then if you ask them why SOA ? They will say agility, they will say reducing costs, they will say enhanced governance and they will say easier evolutivity of the systems (versus siloed and obsolete technologies).

All these answers are plain marketing. These are vendor fictional noveling to sell software and projects. The reality behind this is that most decision makers in IT have no idea on what SOA is about, what’s behind the concept and what it takes to build a real SOA project.

Most people will see in SOA a magic wand that will transform their landscape through some kind of sparkling big bang. All older spaghetti cobol systems magically transforming into futuristic orchestrated services based applications.

The fundamental error is there. They define SOA as a goal instead of a mean.

SOA in itself has no purpose and if your system is working fine, keep it there. SOA must be a base for building new applications that will need to interact with existing systems and need to be able to communicate with future (internal and external) bricks of the landscape . Many technologies are associated to SOA, we may cite Software as a Service (SaaS), Business Process Management (BPM), mash-ups and web applications.

SOA must be derived from a business requirement and should not be technologically driven. It must support the implementation of a business process, that goes through different systems, that needs to be monitored through its different milestones and that might need to take in account fast changes (to keep up competitivity).

Transforming the current landscape into services orientation to reduce maintenance costs is a typical error.  This comes from a common confusion between SOA and web services. While you might want to expose an existing functionality as a service to be consumed by a third party application, you may just build a frontal web service that will be invoked. Rather than doing this, many companies will dive into a complex project implementation [reworking] leading to Neverland.

2- How to make SOA projects successful ?

In order to make SOA projects successful, you will need to assess several mitigation points:

a. Do not expect magic: SOA is costy and do not expect a 80% ROI. SOA projects must be appropriately funded by the each involved Line of Businesse at the appropriate balance.

b. SOA must be driven through business needs. A strict governance should be setup with process owners (functional and technical) that will understand all the underlying requirements of its implementation. These two will then monitor the build and runtime. They should be the single point of contact regarding any subjected related to the process.

c. SOA projects are transverse projects. For this purpose they need a common sponsor at the highest level federating all the LOBs effected by the process dealt with.

d. SOAs are based on the principle of reuse of existing business services (a set of lower level [web] services with a business meaning). For this purpose an in-depth analyze should be carried over all the processes that might potentially be effected by the implementation of the new architecture.

e. The transformation should be carried with the support of an architecture framework (e.g. TOGAF, EAF, Gartner’s).

f. Before the implementation project starts, KPIs must be defined. For this purpose, we need to have a common understanding of what the KPIs are, what will be measured, how, what are the business rules and which thresholds should start a preventive action.

g. SOA requires proactivity all along the implementation. It should reflect the process execution in the real world. Interviews with the key-users should be carried in order to have an end-to-end understanding of the processes.

h. Assess the SOA maturity. Before implemeting a Service Oriented Architecture, the organization must ensure that they have the required level of maturity at both the business and technical level allowing them to reach their targets.

3- Are Service Oriented Architectures really dead ?

Service oriented architecture is just a marketing name to define the principle of resources available as a service. These services represent a business object (e.g. credit check) and are orchestrated in order to create a business process.

While this might look new and innovative, this has long been implemented in several industries, only under different names. The main change today resides into the maturity of the underlying technologies and their standardization. As part of the natural life cycle of an IT landscape, systems will adopt new architectural paradigms, including the service approach. Several technologies are there to stay or evolve. They are coercedly linked to the service oriented architecture.

SOA is there to stay. The only thing that might change is really just the name.

Note: This post was also posted on the SAP Developer Network