Would like opinions on A5's "Security Framework"! Use it, or "Role Your Own"!

[Fulltimer]

In other languages I've always had to write my own security routines. It would take longer but I would have a thorough understanding of what was happening "behind the scenes".

I've written a couple of apps with A5 but have not used the Security Framework.

- Is it robust enough to use on a commercial quality app?
- Does it use DBF or SQL or a combination of both?
- Is the login data encrypted?
- How hackproof is it?
- I've found some videos on security, but can't seem to locate one that starts you out at DAY ONE?

Would like to have some "learned" opinions on this important subject. Thanks!

[Steve Workings]

Re: Would like opinions on A5's "Security Framework"! Use it, or "Role Your Own"!

Many of us had to roll our own before Alpha came out with its Security Framework. Using the Framework is definitely the way to go.

- Is it robust enough to use on a commercial quality app? Yes
- Does it use DBF or SQL or a combination of both? Defaults to DBF, but you'll find documentation on using SQL.
- Is the login data encrypted? Yes.
- How hackproof is it? Very.
- I've found some videos on security, but can't seem to locate one that starts you out at DAY ONE? The Total Training videos cover this if you have 'em.

[JerryBrightbill]

Re: Would like opinions on A5's "Security Framework"! Use it, or "Role Your Own"!

Some facts about the security system to add the what Steve said

• If the security framework is on, every request goes through the security system, even css files, JavaScript files, html pages, Ajax callbacks, images, etc.
• The security is applied in the server architecture and can not be bypassed.
• The framework is based on deny unless specifically allowed.
• There is no measurable speed impact from the security check
• The security authorization data set after login can not be accessed or edited by anyone other than the internal system.
• If the security login expiration is set to "session" (the suggested configuration) there are no cookies or other data stored or passed to the client computer.
• Password encryption is on by default and uses a proprietary process.
• There are a number of cross checks in security code to prevent a user from modifying data to circumvent the security.
• The data can be stored in dbf (default) or any SQL database supported. If your main data in in SQL, we strongly recommend moving the security to SQL
• Security using SQL data uses active Link tables. However, all data access is a direct connection to the SQL database and the Active link tables are just used to define the linkage.
• The framework has been around for a long time, and to our knowledge no one has ever been able to "hack" a properly configured system.
• The security has been used on systems that are required to meet very strict legal requirements, such as systems that must meet HIPAA regulations. Independent consultants have accepted the system as meeting the requirements.

The only problems we have seen center around incorrect configurations. By default, security is applied at the component level. By placing security on individual components as well as pages, security is enforced on any callback as well as original requests. While this can be challenging to configure in a large complex application, it is very secure.

Here are a couple links in the Wiki that explain the system

http://wiki.alphasoftware.com/Web+Se...+Framework+V10
http://wiki.alphasoftware.com/a5/Usi...20Security.pdf
http://wiki.alphasoftware.com/How+V1...Security+Works

[mronck]

Re: Would like opinions on A5's "Security Framework"! Use it, or "Role Your Own"!

The security has been used on systems that are required to meet very strict legal requirements, such as systems that must meet HIPAA regulations

Jerry, against knowing better of course, this is a tricky statement. Many might think, that if they have an app with the AS Security Framework enabled, this app is HIPAA compliant just because of that.
Can you elaborate a bit more on this.

What is the practical difference for the Alpha Developer with regards to application security between "being fully HIPAA compliant", "meeting HIPAA regulations", or "consultants having accepted the system as meeting the requirements"?

[Fulltimer]

Re: Would like opinions on A5's "Security Framework"! Use it, or "Role Your Own"!

Jerry, against knowing better of course, this is a tricky statement. Many might think, that if they have an app with the AS Security Framework enabled, this app is HIPAA compliant just because of that.
Can you elaborate a bit more on this.

What is the practical difference for the Alpha Developer with regards to application security between "being fully HIPAA compliant", "meeting HIPAA regulations", or "consultants having accepted the system as meeting the requirements"?

I too would like a more definitive statement regarding HIPAA and was my concern when starting this thread in the first place.

Tom W.

[Steve Workings]

Re: Would like opinions on A5's "Security Framework"! Use it, or "Role Your Own"!

With a bit of help from your favorite search engine, you can find a slew of definitions, requirements, specifications etc. about what make this stuff HIPAA compliant. It also becomes immediately clear that the definition of compliance is a bit fuzzy, open to interpretation, and ultimately subject to the review of the compliance reviewer. There are also a few standard basics that can be found in almost any set of specs.

My advice has long been that if you're going to build an app with this requirement, see if you can find or consult with whoever is going to be doing the reviewing. A hospital, for instance, will probably have someone in charge of compliance, and I'd have a sit-down with them before going very far.

Now, all that said, you're right. Simply applying the Security Framework doesn't make an A5 web/database secure in the same way that sitting in a garage doesn't mean you're a car. But, Alpha's Security Framework is far and away better than rolling your own to create the security we need (which was the original question here; there was no mention of HIPAA in the original question) -- whether it's for HIPAA or something else.

[mronck]

Re: Would like opinions on A5's "Security Framework"! Use it, or "Role Your Own"!

Yes Steve, your points are valid. BUT. The term "far and away better" is very subjective and most certification programs are about objective specifications. Many applications nowadays need to comply to HIPAA or SAS70 requirements hence it is not a strange question to shed some more light on how the standard Alpha tooling is doing in that light. I doubt that they have ever had their security systems built in with Alpha certified by an audit board. In many situations, the reviewer would simply demand the manufacturer to be certified as well, he really is not going to do extensive research to the products that your system is build in/with. If Alpha would do so and made the certification open for the developers that would make things much easier.

[JerryBrightbill]

Re: Would like opinions on A5's "Security Framework"! Use it, or "Role Your Own"!

Jerry, against knowing better of course, this is a tricky statement. Many might think, that if they have an app with the AS Security Framework enabled, this app is HIPAA compliant just because of that.
Can you elaborate a bit more on this.

What is the practical difference for the Alpha Developer with regards to application security between "being fully HIPAA compliant", "meeting HIPAA regulations", or "consultants having accepted the system as meeting the requirements"?

Good questions. If you are working in any system that falls under the HIPAA regulations, consult a HIPAA expert, perhaps more than one. The regulations are open to interpretation and often different consultants will give different answers. The regulations are much more complex that just access control and include areas such as data encryption and access tracking.

[RichCPT]

Re: Would like opinions on A5's "Security Framework"! Use it, or "Role Your Own"!

Use Alpha's security for what it was meant for - controlling access to specific parts / features of an application. It will take you very far, with just minimal effort. Just plan a good naming convention for your Group names. Alpha lets you apply security to everything imaginable:
- opening components, pages, etc.
- Insert, change, delete record operations from components
- Visability of controls
- Enabling of controls

If you need security access at the database row level then I would just plan to implement that through your application. But if the requirements is that the backend must handle it then things are probably going to be complicated.

-Rich Fulham

[mronck]

Re: Would like opinions on A5's "Security Framework"! Use it, or "Role Your Own"!

A warning though about encryption: Alpha specifically states in its documentation that the encryption is ONLY suited for testing, and that applying A5 encrypting in a production environment is strongly discouraged. You might need to look for a commercial grade encryption tool to do that.

[JerryBrightbill]

Re: Would like opinions on A5's "Security Framework"! Use it, or "Role Your Own"!

A warning though about encryption: Alpha specifically states in its documentation that the encryption is ONLY suited for testing, and that applying A5 encrypting in a production environment is strongly discouraged. You might need to look for a commercial grade encryption tool to do that.

I believe you are referring to encryption using dbf tables. Dbf would not be recommended for any secure system and most production grade systems should be using some type of SQL database. There are many commercial products to encrypt various SQL systems, from basic and cheap to very secure and expensive.

The systems I have worked on that fall under HIPPA regulations all use MS SQL Server Enterprise with TDE. A very expensive, but very secure system that is easy to implement and has virtually no speed impact.

[mronck]

Re: Would like opinions on A5's "Security Framework"! Use it, or "Role Your Own"!

I believe you are referring to encryption using dbf tables. Dbf would not be recommended for any secure system and most production grade systems should be using some type of SQL database. There are many commercial products to encrypt various SQL systems, from basic and cheap to very secure and expensive.

The systems I have worked on that fall under HIPPA regulations all use MS SQL Server Enterprise with TDE. A very expensive, but very secure system that is easy to implement and has virtually no speed impact.

Not quite Jerry....
I am talking about the text in the WikiPedia under the section "Encryption Algorithms (Ciphers)" that you can find here.

I quote:

....Alpha Five and the Alpha Application Server use OpenSSL and its redistributable DLLs in order to provide SSL and other encryption functionality. While Alpha Software distributes a set of DLLs with a limited set of encryption algorithms, Alpha Software makes no claims regarding their usability and takes no responsibility and accepts no liability for their use in customer applications. These algorithms are made available for development and testing purposes only.....