Enterprise Security Architecture is the method of interpreting the business security future state and strategy into actual enterprise transformation by creating drivers, good communication, best practices and models that enable the architectures progression. In order to obtain the future state an organization will need to overcome obstacles in these uncertain times. Having a Security Architecture will allow for agility, and the ability to avoid the pot holes and obtain the organizations future state. Security architecture also leads architecture progress, strategy and execution. The progress should be measured against principles developed in Enterprise Architecture. These principles are the corner stone for evolving the security architecture. The principles help the security architecture strategy move from siloed security undertakings to an aligned future state.
Information streams across business and operational processes is vital for business performance. Data quality, including the source of the data must meet criteria for reliability in order to support business goals. It is important for all Security Architectures to protect its very life blood, better known as Data. To do this it is important to set best practices and bench-marking. A lot of times best practices and bench-marking come as an afterthought but this is not good. I believe that you will be hacked no matter how tight the security is, it is just a matter of when and where, and are you prepared to stop it. It’s like the article reference insurance, and having that peace of mind.
Having an Organization align business goals with security architecture, brings in IT to support those goals a lot sooner than later. This allows for agility for the organization opening such windows as utilization of cloud, digitization which would improve employee work performance, new opportunity on revenue streams, and big data analysis which would improve executive decision making that would lead to more efficient work load on systems and employees. Organizational betterment’s such as these will deliver executive buy-in in no time, and have the stakeholders clamoring for more improvement developed by the Security Architecture Team.
FERPHA is the Family Educational Rights and Privacy Act (FERPA) (20 U.S.C. § 1232g; 34 CFR Part 99) is a Federal law that protects the privacy of student education records. The law applies to all schools that receive funds under an applicable program of the U.S. Department of Education. FERPHA gives rights to the parents with respect to their children’s education records. These rights transfer to the student when he or she reaches the age of 18 or attends a school beyond the high school level. Students to whom the rights have transferred are “eligible students.”
These rights allow the student or parent to view the data of the student. If the student or parent makes this request, the institution must comply within 45 days. Furthermore, FERPHA has types of data with three 3 categories: educational information, personally identifiable information, and directory information. FERPHA requires different levels of security for each category. Personal and identifiable information requires approval from the student or parent before the records can be released. Directory information does not require approval, unless the student has opt-out, and in this case the institution cannot release the data. These two types of data are similar and related but handled differently. Education record is considered student’s transcripts, GPA, grades, social security number, and academic evaluations, courts have also included in this category certain psychological evaluations. Educational institutions are now permitted to adopt a limited directory information policy that allows the schools to disclose designated information to designated parties. To create such a policy, however, educational institutions must provide notice to parents or eligible students. Over all to share an educational record permission from the student or parent is required.
As we talked a little about FERPHA data, I would like to purpose for my readers to think about how this type of data should be handled in a security aspect. Does it require the utmost attention such as PII and HIPPA data? Recently, I have been in some conversation to where FERPHA data was brought up, and where this type of data shouldn’t be considered high risk and shouldn’t be secured as such, instead it should be considered medium and not so critical. In my belief this data is just as important as any data at a hospital or bank, but yet higher learning institutions are taking a look at their security architecture, and looking to lessening the severity of risk. The security of FERPHA data is important for building trust and credibility with not only the student\parent, but accreditation institutions as well. Also, with a clearer understand of these policies and procedure brings a mature education institutions.
Software and system security design is building an infrastructure and software systems that combat and prevent against malicious attacks. Security holes related to deficiencies in code or system bugs such as poor error handling and not keeping up with vendor security patches. These types of miss handling with security can cause organizations millions, by allowing malicious intruders, SQL injection and loss of data just to name a few. Increasing use of the cloud and web facing application these types of security risk are only going to increase. Based on the article (http://www.cbsnews.com/news/percentage-of-companies-that-report-systems-hacked/) more than 80 percent of U.S. companies have been successfully hacked. Successful attacks by hackers involved stealing, changing or making public important data, according to the survey. Smaller companies (those with fewer than 1,000 employees) were more vulnerable, with 85 percent saying their information systems had been broken into. About 60 percent of larger companies reported successful hacks.
Best Practices suggest to incorporate security early in the life-cycle. Designing for security threats will help reduce risk and build better testing and analysis. In turn building faster and secure systems. It is now time to institute software security design principles. In doing organizations will lessen the risk off attack. The principles are listed below
• Least Privilege – Giving users rights what is needed to do their job.
• Fail-Safe Defaults – User cannot gain access to resources to which they don’t have access to the data. Unless they have access to the data themselves
• Economy of Mechanism – systems should be designed as simple and small as possible
• Complete Mediation- Resource must have validation for authorization
• Open Design- security is not design secrecy
• Separation Privilege- Access should not be granted on a single condition IE. DUO
• Least Common Mechanism-Access resources should not be shared
• Psychological Acceptability- security mechanisms not make resources more difficult to access than if the security mechanisms were not present
• Defense in Depth- Layer resource access IE web access and saml2
It is import for architects of security to know when a principle is needed and when to forgo a principle. It is also important for security architects to consider policies and regulations that organizations might have to adhere to such as HIPPA and FERPHA. One other thing to consider is what overhead the added security will apply to the underling infrastructure. Security architects is not all about saying no, it is about balancing the pro and cons on risk, systems performance and user experience, so to deliver the best user experience within budget and stakeholder requirements.
Mitch Lipka – http://www.cbsnews.com/news/percentage-of-companies-that-report-systems-hacked/