|
OpenPMFOther Products
|
 OpenPMF helps develop, operate and maintain secure applications. It makes application security proactive, manageable, intuitive, cheaper, and less risky.
 |
What is OpenPMF "security policy automation"?
Unlike any other application security policy management product in the market, OpenPMF offers unique automatic technical policy generation and update from intuitive business security requirements (even for agile SOA, Cloud and virtualization application platforms). Other products and approaches do not offer this level of automation, which means developers and security administrators need to define technical security policy rules manually, and update them whenever the IT landscape changes. The result is a maintenance cost explosion. OpenPMF's policy automation reduces the maintenance cost close to zero! |
|
How does OpenPMF "security policy automation" work?
OpenPMF's policies are captured in generic terms (so-called "models"), rather than in technical security rules. This way, OpenPMF policies typically do not have to change when the application landscape (e.g. web application interactions) changes. OpenPMF automatically generates the technical security enforcement rules from those models by automatically analyzing the applications with all their interactions, and inferring which rules are required to enforce the requirements defined in the models. This approach is called "model-driven security". It applies some of the concepts from model-driven software development to security. OpenPMF's patent-pending model-driven security feature ensures policies are manageable even if IT landscapes are large and change dynamically. Its automation also improves the correctness of the enforced security (in comparison to manual specification and continuous updating of technical rules). The result is a significant cost saving, esp. with respect to maintenance. |
|
Why should I care about OpenPMF "security policy automation"?
Without OpenPMF, creating many fine-grained technical security (esp. for access control and auditing) rules is too costly, cumbersome and error-prone. And - even worse - without OpenPMF, updating many fine-grained technical security rules whenever the application landscape changes results in a maintenance cost explosion. OpenPMF automates much of the policy creation, and reduces the update maintenance cost close to zero.
|
|
Why is application security important?
Industry specialists agree that over 70% of all security break-ins happen on the application layer, not on the network layer. In order to ensure that enterprise security policies and regulations are adequately addressed on the application layer, matching fine-grained access policies need to be enforced reliably and consistently. And at low cost and low maintenance. Without application access control and auditing, enterprises would leave the most important layer in their IT landscape unprotected.
|
|
What aspects of application security does OpenPMF cover?
OpenPMF mainly focuses on application security policies for access control and auditing. This is called "authorization management", and is a critical part of today's application security strategy. |
|
Does OpenPMF do whitelisting or blacklisting?
OpenPMF is a whitelisting technology, i.e. it explicitly allows good accesses and denies everything else. This approach is more reliable than blacklisting, which explicitly blocks known bad accesses but allows everything else. Using conventional methods, whitelisting is hard because many rules have to be manually written - OpenPMF solves that challenge with its unique policy automation approach. |
|
What can I exactly do with OpenPMF?
1. Configure intuitive business security requirements
2. Generate matching technical security policies automatically
3. Enforce technical security policies transparently
4. Audit technical security policies transparently
5. Update technical security policies automatically |
|
What kinds of policies can I define, enforce, and monitor with OpenPMF?
OpenPMF policies can either be default security policy model templates, or tailor-made security policy models . Default policy model templates includes policies such as "only allow the interactions the application developer has programmed; deny and log everything else", or "only allow access to SOA services based on the sequence of the BPM workflow used to orchestrate the SOA". Tailor-made security policy models include aspects of compliance regulations and enterprise security policies, e.g. "doctors are only allowed to access their current patients' health records; if anything else is accessed, access is not denied, but an audit log entry will be generated". |
|
Which development tools can I use OpenPMF with?
OpenPMF supports Eclipse and the Eclipse-based Intalio BPMS (SOA with BPM) application development tools out of the box. If needed, we can also port OpenPMF to your IDE. |
|
What kinds of application platforms does OpenPMF support?
OpenPMF supports a wide range of application platforms, including: Axis2/Tomcat, Weblogic, Glassfish, RTI DDS, Intalio BPMS, Eclipse, ActiveMQ, XACML, Qedo CCM, MICO & JacORB CORBA, XMLBlaster. OpenPMF supports more technologies than any other authorization management product in the market. |
|
How does OpenPMF support application agility and Service Oriented Architecture (SOA)?
SOA is often designed with dynamic change (agility) and reuse in mind. SOA is also often built using web applications. OpenPMF can automate policy generation, enforcement, and update for such application landscapes in such a way that technical security enforcement rules can be automatically updated whenever the interactions between web applications change. Without OpenPMF, security administrators would need to manually update technical enforcement rules whenever the application landscape changes. |
|
How does OpenPMF support Cloud Computing?
Currently, OpenPMF can be tied into the web application server infrastructure in the cloud. Soon, we will also release our new OpenPMF Cloud version, which can be managed using our subscription based cloud service.
|
|
What are the benefits of using OpenPMF?
1. Save time and money: Security professionals focus on security without the need to be application experts. Application professionals focus on the application without the need to be security experts. OpenPMF automatically generates & updates application security policies for them. Security & development are separated, but linked via OpenPMF's policy automation.
2. Adopt security easily & flexibly: OpenPMF ties into application development and runtime tools, with multiple licensing alternatives and gradual adoption options available. Developers do not need to train to become security experts, all they need to do is push a button to automatically generate policies.
3 Align business & security, improved proactive security & agility: OpenPMF removes security silos (even with legacy technology). OpenPMF also includes comprehensive, fine-grained security monitoring & auditing. |
|
Can OpenPMF also enforce security policies for IDSs, databases, firewalls etc.?
Yes. OpenPMF already supports IDS (Promia Raven), firewalls (IIOP ObjectWall), databases (Secerno, PostgreSQL), and LDAP, X.509, OMG ATLAS. We can also enhance OpenPMF to cover any particular other technologies you need to enforce security policies for. |
|
How does OpenPMF give me consistency and agility support?
OpenPMF centrally stores policy models that are automatically turned into technical access control and audit rules, which are then consistently enforced for all applications which are protected by an OpenPMF policy enforcement point (PEP). |
|
Do I need to modify my application code to use OpenPMF
No, OpenPMF's policy enforcement points (PEPs) are typically installed in the middleware platform, so that policies are enforced without the need to embed anything into the application code. |
|
Is OpenPMF standards based?
Yes, OpenPMF is standards based (inc. BPMN, XACML, Syslog, X.509, ECORE/MOF), and all internal formats are available to customers. |
|
How is OpenPMF licensed, and how much does it cost?
OpenPMF is available as multiple licensing alternatives and gradual adoption options, including out-of-the-box (Eclipse, Intalio BPMS) licenses, custom deployment licenses, leasing & subscription contracts, virtual appliance, hardware appliance. |
|
Does OpenPMF fit in with my Identity and Access Management (IAM) + Single Sign-On (SSO) infrastructure?
Yes. Most IAM products focus more on identity and role management than on fine-grained application authorization. OpenPMF therefore complements IAM deployments: identities and roles from IAM deployments can be imported into OpenPMF via the LDAP standard. By the way, OpenPMF also relies on authentication mechanisms provided by the middleware (e.g. SSL) or an SSO solution. |
|
Has OpenPMF been successfully deployed and peer-reviewed?
Yes, OpenPMF is proven technology, with deployments including US Navy & Air Force & a European air traffic control project. The scientific principles behind OpenPMF have won several industry awards, and have been vetted by numerous scientific groups |
|
How does OpenPMF fit into my secure software development lifecycle (SDLC)?
OpenPMF 3.0 is part of a secure application development lifecycle at development time right from the beginning – dealing with policy abstraction, externalization, authoring, automation, enforcement, monitoring, and verification. OpenPMF gets triggered at various points in the SDLC from within the integrated development environment (IDE) - offering unique "click-of-a-button" security policy automation for developers! |
|
Does OpenPMF help me with intrusion detection/prevention (IDS/IPS), auditing & compliance?
Yes. OpenPMF adds the critical application layer monitoring on top of conventional network IDS/IPS products. OpenPMF centrally collects incident alerts for anything other than allowed accesses (e.g. blocked requests to the application). OpenPMF also supports explicit audit policies, which trigger an incident record instead of a granted access. OpenPMF can export its application layer alerts into IDS/IPS, auditing and compliance tools using the Syslog standard. |
|
Does OpenPMF tie in with other authorization management solutions?
Yes. While OpenPMF includes a wide range of policy enforcement points (PEPs), it also supports exporting generated technical security rules in the OASIS XACML standard format for use by third party authorization management products. |
|
How does OpenPMF compare to static/dynamic application vulnerability scanning, testing, and analysis tools?
OpenPMF is about generating authorization and audit policies for applications when they are built or changed. OpenPMF is about enforcing security & compliance policies across your application landscape. OpenPMF is not about testing code quality, or finding static/dynamic application vulnerabilities. Both application security approaches are required and are complementary. |
|
Finally, what do the buzzwords used to describe the uniqueness of OpenPMF actually mean, and how can I compare those features effectively with other products?
Automation:
As the name implies, automation takes the human out of the loop. Automation includes. Policy automation involves: (a) without human interaction, translating policy requirements into technical implementation, e.g. access control & monitoring, authentication, (b) without human interaction, enforce technical security policies across applications and systems, (c) without human interaction, collect, analyse, and remediate incidents. Anything else is not automation: e.g. collecting incidents and presenting them to a user so that they can manually remediate. The simple test: If it involves the human at runtime to enforce security, then it's not automated.
Proactive:
Proactive is related to "preventive", i.e. when the product enforces security based on that policy that states what should be allowed and what should not be allowed, irrespective of any monitored incidents. This means that bad things are prevented before they happen, instead of fixing the damage after it happens. Security enforcement based purely on "reactive" action based on monitored incidents is not proactive. Proactive means that the security product knows what should be allowed and what should not (= policy) before any activity happens across systems and applications; Proactive inherently implies that the product needs to capture the policy, which the next topic "policy-driven" is about. Proactive is inherently a wobbly term, so ask for specifics, esp. whether the product is preventive.
Policy-driven:
Policy driven means that the security product knows and captures what should be allowed and what should not (= policy) before any activity happens across systems and applications. This means someone has to type in the policy in some form (in model-driven security, you capture generic requirements models; in e.g. firewalls, you type in many technical rules). This is often called "white-listing", and white-listing policies have been traditionally difficult to manage - it is expensive, error-prone, and time-consuming, esp. in agile IT environments. Model-driven security helps address that policy management challenge (this is explained in the beginnings of this blog). According to that definition, tools are not "policy-driven" when e.g. compliance decision support tools tell you based on collected incidents that you are not meeting your compliance policy. As you can see, this term can be turned into meaning almost anything, so if a vendor says "policy-driven", the best thing to do is to ask for the specifics.
Enforcement:
Enforcement means that the product ensures the policy is actually enforced. For example, a firewall that blocks traffic based on the policy proactively "enforces" the policy. Sounds obvious, but many vendors that do not have enforcement capabilities (usually because they cannot capture policy in a suitable way) have twisted this term to mean that the product presents some information (e.g. about incidents) to a human user who can then manually take steps to remediate the problems found. This is not enforcement, this is remediation. Again, the terms are turned into meaning almost anything, so ask for specifics.
Application security:
This is a tough one because it is such a broad topic. Be aware that there is much more to application security than what gets visibility these days (static/dynamic code analysis, executable whitelisting etc.). Applications today are definite to an increasing extent by how they interact (e.g. SOA & Cloud mashups), so it is important to enforce security policy based on many application attributes (e.g. application, interactions, application context, execution/use workflow etc.). It is very important that application security is not only about vulnerabilities, but also about application behavior - a perfectly correct application can be used by a user in the wrong context to do something they are not allowed to (esp. by insiders). Make sure you are not talked into "application security is only xyz" by vendors.
Model-driven:
For completeness, here is the main uniqueness of model-driven security. It allows security requirements to be captured in generic terms (models), which are semantically so close to human thinking that they cannot be directly enforced by a computer. Model-driven security translates these models into concrete computer-enforceable technical rules by analyzing the applications with all their interactions (at development/deployment time) and context information (mostly at runtime). This step from "human thinking" to "machine enforceable" is what other policy management approaches do not achieve: whatever the format or representation, in those other approaches you still have to input technical security policies. Read up below, or contact us if you would like to know more about this.
|
(last updated: 06 October 2010)
|
