MAMP is best helper for coding PHP apps on OS X I've found since Textmate.

The abbreviation MAMP stands for: Macintosh, Apache, Mysql and PHP and it installs as a simple OS X application (drag folder into /Applications). Once you run it it starts up a local Apache and MySQL and shows a simple control panel which you can use to administer them. A full PHP stack is also included (either 4 or 5).

I was using the local Apache and PHP but this is actually much easier to work with, you can change configurations easily, making working with multiple sites much quicker. Although I don't use MySQL at this point (SQLite works for the small sites I am doing) I imagine it's a big help there too.

There is a pro version as well with many more features for managing testing and deployment of larger sites. It also supports external viewing of different sites for folks who want to let others see their progress. Base MAMP is not for serving to the public.

Sure you can do it yourself locally but this makes it totally painless.

My Tags: php macosx

HIPAA (Health Insurance Portability and Accountability Act of 1996) is a big law which covers a whole host of things in the realm of healthcare in the U.S. Although the phase-in of its many parts are almost complete, the changes are still rippling across the country. Why a topic for this blog? I recently worked at a healthcare company and got to learn a whole lot of about it and its impact on privacy, security and IT.

Why Should I Care?

If you are alive in the U.S. HIPAA affects you. Most people have very little idea of what it is and what those affects (both public and behind the scenes) are, so I thought I would share what I learned.

HIPAA Overview

HIPAA has a number of sections, divided into two Titles (I) Health Care Access, Portability, and Renewability and (II) Preventing Health Care Fraud and Abuse; Administrative Simplification; Medical Liability Reform. Title II is further broken up into a number of rules (1) Privacy (2) Transactions (3) Security (4) NPI and (5) Enforcement.

Generally (I) and (II,1) are what the general public sees. Everywhere you go you need to give permission for people to look at and access your healthcare information; and finally you can take your healthcare coverage with you when you switch jobs (provided you follow the rules) and not be denied coverage. At my local pharmacy for example you can't stand in line direct behind someone picking up a prescription (so you can't see what they are getting).

Privacy

The key term for this type of private healthcare information is called "PHI", which means Protected Healthcare Information, and is relatively well defined. This type of data is anything relating to your health care and any information which might tie you to your healthcare (even such details as phone numbers or your geographical information, and certainly stuff like your SS number). Access to this type of information is restricted to those (1) you give explicit permission to (2) or those who have implicit access, name entities like Insurance companies and clearinghouses (more on those later). Even with either permission, there are many rules on where and how and how much access is enough and what must be done to protect it.

If it sounds onerous, you are right, it's supposed to be. It's your personal information of a nature you really don't want anyone to casually have access it. Before HIPAA, all of your medical and personal information could be accessed by anyone anywhere in any fashion without any real consequence. The wild, wild west of the 1850's had more law that this.

Electronic Information

The law however goes way beyond simple portability and privacy: the other major part of this was to standardize how medical information was transmitted and shared electronically. Before HIPAA everyone was free to describe health care information in any way they felt like; filing a claim with an insurance company was an exercise in futility as every one had different forms, different codes and even then you were lucky it didn't change without any notice. Electronic (EDI) claims were basically a joke unless the doctor or hospital limited coverage to very few plans.

HIPAA provides (1) a standardized set of transactions for different uses (2) a defined (and continuously updated) set of codes to define virtually anything in a consistent way (like a diagnosis or test or explanation). The upshot of all this is that a healthcare Provider can now file and interact with a Payer either directly or more generally, via a Clearing House) electronically and mostly be assured of success in the transaction.

One further addition that only recently became required (for the most part) is NPI, the National Provider Identifier, which uniquely identifies all entities using electronic communications. Think of it as an IP address for healthcare. Note that the NPI defines the entity, there may still be additional identifiers such as a DEA number for a drug prescriber.

Security

You might think, I don't care really, I just go to the doctor and get well, and get irritated by all those blasted forms I have to fill out giving permission. That's where the other parts of HIPAA affect you, even though you don't see them. It's called the Security rule (and its brother, the Enforcement rule).

An electronic healthcare claim (I was working on the validation engine at a clearinghouse) is a wealth of personal information, highly suitable for (1) identify theft (2) blackmail (3) job loss (4) fraud and (5) mischief. Being a standardized coded chunk of information (generally in the X12 EDI format) in plain text it can be ripe for criminal usage. Protecting it during processing, storage and transmission is crucial otherwise there is nothing keeping it from becoming your worst nightmare. The Security rule covers a number of safeguards which must be followed to (hopefully) ensure that these nuggets of gold don't become someone's idea of a profit center. The rule covers (1) Administrative (2) Physical and (3) Technical safeguards, basically having procedures to protect the data from various forms of theft or attack.

Remember there are both explicit and implicit access to this data. Generally you give explicit permission to healthcare Providers (like your doctor or dentist), but Covered Entities (as they are official known under HIPAA) such as clearinghouses and insurance companies are granted implicit permission. Imagine if everyone who touched a healthcare claim had to obtain a consent form; the whole electronic system would collapse. So the law allows these folks to handle your PHI with the big requirement that they must follow all of the Security rule or face the Enforcement rule.

Insurance companies and HMOs are people everyone knows (and generally dislike as well). Clearing houses are not something most people even know about. Since HIPAA made electronic claims and other transactions available, most of this traffic is handled by thousands of these entities (from huge to one person places) who act as the intermediaries between the Providers and the Payers. Think of them as routers. Often a claim will move from a provider through multiple clearing houses before finally winding up at a Payer; then responses (such as rejections or notices of payment) flow the opposite way. The whole system is like a HipaaNet!

Enforcement

So what keeps your information safe? It's the Enforcement rule and is both really scary and really wimpy at the same time.

Generally each HIPAA violation can get an individual violating the basic rules a $100 fine up to $25,000 which doesn't sound all that bad. However the real teeth is knowingly violating the more serious rules which are considered a criminal felony, which can result in a year in jail and $50,000 fines for each violation. The documents I have read discussing how this applies seems to show that the government, if it cannot determine a precise number of violations, will use statistical calculations to come up with a number (e.g. you knowingly allowed someone to steal an unknown amount PHI from claims in your database with no audit trail, you processed 1M claims last year, we'll pick some percentage and thats the violation). Violations in a Covered Entity are supposed to be the higher penalties since they have the highest need to protect the information, and the penalties would fall to the corporate officers if no individuals can be found to blame.

For any healthcare provider, payer or clearinghouse, the penalties are pretty scary, and in the worst (and not unlikely) case a business-ender if convicted. So far it seems that the Provider community, which is generally liable for the lesser fines, has gone out of their way to be careful. So far very few prosecutions have actually happened, and that's the sad part, as there are no actual requirements for specific audits, and the government office responsible for enforcing HIPAA (CMS, the horribly named Centers For Medicare and Medicaid Services) will only investigate if a formal complaint is received. Violations of the privacy portion are handled by yet another agency (Office for Civil Rights).

Thus your HIPAA healthcare privacy and the security is tightly controlled yet loosely enforced. Are you at risk? Probably, at least until some major violators are prosecuted and publicly whipped. Like so many things in security (and even personal things like backing up your hard drive) nothing much happens until something really bad happens. Ask TJX about security and bad publicity.

HIPAA is a massive but generally well written law which was badly needed; it has made healthcare privacy, portability and transactability possible and public. How effective it is remains to be seen.

In a following post, I want to cover what a health care claim technically looks like.

My Tags: law it hipaa

In my current project at home I had need to build a plain text report (for an email) which will be temporarily saved in a database in its final form.

Naturally I wanted to use PHP5 to generate the report layout since it is after all a templating system. It turns out to be quite easy to do.

// define data here, referenced in the report
if(ob_start())
{
  include_once 'inc/registrationreport.php';
  $str=ob_get_contents();
  ob_end_clean();
}

// in in the report, lines like:

Name:         <?= $reg_firstname ?> <?= $reg_lastname ?>

Birthdate:    <?= $reg_birthdate ?>

Easy as pie. The only odd thing was making sure I wound up with the right linebreaks I had to add blank lines after the data references. You also have to make sure that the ob_end_clean() is properly balanced with the ob_start() or interesting things begin to happen.

Yes, I know that the short form is deprecated.

My Tags: php

How Does Your Organization Handle Production Access?

In the past 10 years or so I have worked at, or as projects in, many different types of organizations and there are as many different ways to handle production security as you can imagine. Every kind of process from "we don't need no stinking production security" to "we won't even acknowledge we have production systems".

In most companies hardware and software systems are broken up into several categories, generally some kind of location development environment, perhaps a global development environment for initial testing, a higher level functional test area, a QA area and finally the operational production systems. The latter is where the company stores and handles whatever business data that supports or even is its business. For some entities this data is not central to the business, and its loss or theft (if there is even anything to steal) has no real impact on the bottom line. In more cases this data is vital to the continuing health and welfare of the business and care must be taken to avoid loss or alteration. In other companies this data contains private information of others, such as personal, financial or medical information, for which the loss of alteration could result in bad press, civil or even criminal penalties.

Yet I haven't found a consistent view on security at all. Some places have had tight security yet the data and systems were totally innocuous; other places adopted a "laissez-faire" view that allowed full access to anything anyone wanted despite a vast array of public trust information. Sometimes the level or security was based on the anality of the operational leadership rather than the nature of the systems and data.

It never fails to amuse me when I read about a big data loss, may it be unencrypted backup tapes or laptops that are lost, or hacked in systems that provide a wealth of credit card numbers (TJX Post). I always wonder how people got into positions of security leadership without being at least prudent, much less paranoid, about how information and systems at their organization are protected.

The types of security I have witnessed include these types:

• Total Lockdown - only a few operation people have access to all production systems period. Even production logs must be requested and are scrubbed before viewing.
• Mostly Lockdown - only a few operation people have access to all production systems but specific access is granted to other individuals who need it based on limited username/passwords with full audit trails
• Mostly Lockdown 2 - like the previous but allow more full access but from limited IPs, using electronic keys
• Careful Lockdown - only a few operation people have access to all production systems but other users have specific access rights to areas which have been set up for them (such as log directories)
• Come On In The Waters Fine - production is protected by passwords known to everyone. No audit trails are possible since it's a shared "secret" other than possible recording an IP address.

Financial entities such as banks and investment companies, healthcare companies and the like you would think always operated in a lockdown mentality but in my experience it hasn't been universal. In one place I saw total lockdown, but the reason had more to do with hiding the failures of the operations team than any real desire for tight security. I have often heard the excuse for a "Waters Fine" system that people need quick access to solve production problems; also since the outer security walls of the company are so solid that no possible issue exists with external attackers hitting internal systems. [I'll pause while you either laugh or gag].

When I was working on a big project at a large company (customer) around 1999, me and my project partner initially had access to both our test and the production systems (generally during most the 12 month development and beta roll out) which ran in a small data center on the same network. This system had both an external web application for the external customers and an internal one for the team that processed the data. The database was highly complex with both full audit trails and a workflow system. We were given access to the network with username/passwords/ip filtering/electronic key generator but otherwise allowed to do the work. Near the end of the project the company hired EDS to take over operations and all of our access was completely revoked, making it impossible to actual continue the project in any reasonable way. We were limited to calling an operations person who would type into a command line what we needed done, and have them read the result to us over the phone. Yet the two of us were the only people would were able to do anything with the code or database so progress came to a complete halt. So we did what enterprisey programmers always do; we put a backdoor into our application (protected by two levels of passwords and IP filtering) with full access to both databases. Needless to say it worked because EDS didn't care about the application or the project at all, and the folks we were building it for only cared about getting the system finished and working. Eventually the entire system was automated to the point that the backdoor was no longer necessary (and more sane access put into place anyway).

The point is that there is always a balance between the need for some access to production systems with the need to protect them.

So what can go wrong? Unfettered access to systems that should be secure can lead to:

• Errors
• Mischief
• Theft
• Blackmail

I'm sure you can think of more. Yet every day you read of people who failed at the basics of how to properly protect their production systems or data.

Statistics show that most operational security problems come from inside your own staff, yet defending against the proverbial "hacker" from outside seems to pervade most corporate security discussions.

I can see the most reasonable path has to be tough protection combined with limited, fully auditable access. Sometimes it's hard to imagine how to do this since systems, software, databases and platforms are not consistent in how they provide access, authorization and authentication, much less provide easy single-signon interoperability. These types of challenges often lead to diminished security since it's considered "too hard" to overcome and thus nothing is ever done. Sometimes the cost of doing it right seems too high compared to doing the easy way (or not doing anything at all) and hoping for the best. Hoping is not a great security system. It's like leaving your house unlocked and hoping no one will open the door and take your stuff.

I'd love to hear stories from other folks on what people are doing in their companies.

My Tags: security

The 'Anti-Java' Professor and the Jobless Programmers

Reddit comments

In this rather inflammatory article, Professor Robert Dewar seems to belittle almost everything but his own inflated ego and the language he makes his living on.

I can only imagine how sad it must be for someone to be so out of date. Like an aging rocker who can't escape his hair-metal days, he clings to the idea that what was important in the 80's is still no less important today. Concepts which predate most modern applications are still the only right way to teach student how to become useful programmers; as if we should still teach hunting and gathering just in case it becomes necessary for survival.

I started in 1981 as a software engineer working for a defense contractor right out of graduate school. No, not CS, but Chemistry. I've only had 0.5 college hours of computer science (and only that to gain precious computer access) yet I've forged a long career at the leading (and sometimes bleeding) edge of technology since. Unlike the dear Prof I've actually had to change with the times and grasp something new every day of my career, moving swiftly from Basic to assembly to Pascal to C to C+ (sort of) to C++ to Objective-C to Java to PHP and moving forward to Ruby, Groovy, Scala, Erlang or whatever is next. This industry has changed from mainframes and superminis to PC's (and Macs), from terminals to client-server to web applications to programming on a damned phone (oh AT&T Where IS My IPHONE). The thing is, programming is all about change, working with change, dealing with change, being changed.

The only thing that never changes is change itself. And Professor Dewar apparently.

Java is not a bad language, neither is Python or Lisp or Scheme or Erlang or Ruby or PHP or dot dot dot. Maybe BrainF*ck is a bad language, but then it's supposed to be. Programming is all about writing programs that people use (or sometimes machines). It's the only way to learn how to program. You can't teach people how to program, you can only help them along but Computer Science (what a stupid name) isn't about teaching people to program; it's all about teaching them to teach computer science to other people who think they are learning programming.

I've never met a programmer with a computer science degree unless they already were programmers before they ever started. Graduates become programmers like everyone else: when they starting writing real programs for real people. In real programming languages. Like Java or Lisp or PHP or (name your poison). So asking a Computer Science Professor about programming languages and programming is like asking a hot dog vendor to explain hitting a 96MPH baseball 514 feet.

Ada was designed by a committee and started appearing just as I left GD in late 1984 (to program in C, on a Mac no less). Its direct predecessor, Jovial, was what I worked with (mostly on compiler runtimes and tools), and was a fairly nice language for its day. Ada appeared to be a conglomeration of every feature imaginable and seemed perfect for defense department projects (over time and over budget here we come). Imagine if the web had started out in Ada. The first browser would have been out in 2014.

Dissing Java is popular and I can forgive that. Denigrating the web as insignificant is unforgivable today. Somehow thinking of Google or yellowpages.com as some meaningless web applications that any clever child could write and thus is ripe for exploitation by some other clever child is sort of silly.

Sure, I might not want to write the Space Shuttle code in PHP, but look at the good all those expensive $7000 lines of code did: they still lost two of the shuttles to system failures. Another thing no Computer Science Professor would ever think of, that programming is only part of the system. There is a whole lot more to the world that a program lives in then whatever stupid programming language the stupid programmers (who are not Computer Scientists of course) came up with. Like UI design, testing, hardware, scalability, maintainability and a host of other unScientific ilities. Even how to deal with stupid management and development methodologies also favored by our Computer Science elite and still somehow get the project done.

I think that Professor Dewer might consider exiting his flask and talking with people in the real world occasionally, unlike his customers who live in DOD land. Maybe he might even consider contributing some code to an open source environment to show his deep insight and mighty programming ability. Even BrainF*ck could use a dose of Science.

Yes every language sucks but a good programmer with an open mind, an open Google, and a wealth of cross language and cross project practice, can write anything in any language.

Even Java. Or BrainF*ck. Or (lordy no) Ada.

My Tags: languages java humor essay