krypted.com

Tiny Deathstars of Foulness

The increase in the use and complexity of technological assets in the healthcare sector has been on the rise in the recent past. Healthcare practitioners have moved from recording data manually to keeping Electronic Health Records. This eases the accessibility and the availability of data to the health practitioners. Further, electronically stored data makes it possible for patients to receive high quality and error-free care, improve decision making process because medical history is available and also makes it possible to provide safer and more reliable information for medication. Despite, the numerous advantages that the use of technology in healthcare has, there is also a threat of patients data leakage that lingers around. According to a research by Garrison and Posey (2012), medical identity theft has far more consequences in comparison to the typical identity theft. In average, every medical theft case can cost $20,000, and represents a substantial privacy violation. For this reason and more, it is important for healthcare institutions to protect patient data by securing technological assets within the institution. This article will explore the different methods used to secure the technological assets, with an emphasis on mobile devices. The first method is limiting access to the electronic health records to only a few individuals. According to Gajanayake et al.(2014) suggests that there are different models of limiting access to the records. The first step is to ask for authentication, this will prompt them to verify their identity. This could be achieved by giving the authorized individuals unique passwords for identification and also by performing biometric scans of the individuals. This step will eliminate the possibility of unauthorized access to the technological access. The second step is to limit the type of information that one is supposed to access. This could be made possible using certain access models. Examples of models that have been proposed include Discretionary Access Control (DAC),Mandatory Access Control (MAC) and Role Based Access Control (RBAC). The DAC restricts access to certain commands such as’ write’, ‘read’ and ‘execute.MAC controls access by assigning information different levels of security levels. RBAC is based on the rights and permission that depend on the roles of an individual. These models normally apply to the security of electronic data. Other assets such as the hardware could be protected physically by limiting authorization to their storage rooms and also limit the location in which they are expected to be used at. Limiting access ensures that those that are not authorized to access the information are locked out of the database.Hence, this is an important strategy in protecting patients’ data. The second method is through carrying out regular audits on the electronic system and the individuals handling the technological assets. Audit controls record and examine the activities that involve access and use of the patients’ data. This can be integrated into the Electronic Health Record (EHR) system or used to monitor the physical movements of the individuals that have access to the records. In addition, HIPAA requires that all health institutions that use the EHR system should run audit trails and have the necessary documentation of the same (Hoofman & Podgurski,2007). Some of the information collected during audits includes the listing of the content, duration and the user. This can be recorded in form of audit logs which makes it easy to identify any inconsistencies in the system (Dekker &Etalle ,2007). Further, monitoring of the area where the hardware have been placed for used should be done. This can achieve by use of recorded video, which monitors the activities of individuals who use the system. This can also be audited regularly and any inconsistencies noted (Ozair et al., 2005) Carrying out audits of the technology assets of the healthcare institution will help to monitor the daily use of the system which will enable the identification of any abnormal activities that may endanger patients’ data. The third method is the setting up of policies and standards that safeguard the patients’ data. These policies may vary from one institution to another. For instance, the employees should be prohibited against sharing their passwords and ID and they should always log out their accounts after accessing the system. The authorized individuals would also be properly trained about these so that they are aware of their importance. In addition, these policies should be accompanied by consequences which will impact the users. This will ensure that they follow the policies to the letter. The set of policies and standards are to ensure uniformity in the protection of patients’ data (Ozair et al., 2005). The fourth method that could be implemented to protect patients’ information is through the application of various security measures to the software and the hardware. The software can be protected through encryption of data, using firewalls and antivirus software’s to prevent hackers from accessing the data. Intrusion detection software can also be integrated into the system. These measures will protect the data from individuals who intend on hacking into the system online and accessing information for malicious purposes. The hardware could be protected by placing security guards at different stations where patients’ data is stored so that he ensures that no unauthorized person gets access to the area or no one tampers with the system or steals it. This step will ensure that the hardware is kept safe from intruders and people with malicious intent. Protecting patient data starts with the software systems that house the data. The databases that warehouse patient data must be limited to only those who need access and access to each record must be logged and routinely audited at a minimum. Data should only reside where necessary. This means that data should not be stored on devices, at rest. For Apple devices, device management tools such as the Casper Suite from JAMF Software both help to keep end users from moving data out of the software that provides access patient data, and in the case of inadvertent leakage of data onto unprotected parts of devices, devices should be locked or wiped in case of the device falling outside the control of a care giver. Finally, the integrity of devices must be maintained, so jailbroken devices should not be used, and devices and software on devices should always be kept up-to-date, and strong security policies should be enforced, including automatic lock of unattended devices and strong password or pin code policies applied. In summary, the protection of patients’ data in this technological era should be given a priority. In consideration of the frequency and losses that are experienced due to leakage or loss of private patients’ information, more should be invested in maintaining privacy and confidentiality of data. This can be achieved through controlling access to the electronic data and the gadgets that hold it, carrying out regular audits on the access of the system, creating policies and procedures that ensure that data is secures and finally through, putting in security measures that guard against loss and leakage of the information. All these measures will aid in alleviating the risk of patients’ data and maintaining their privacy and confidentiality which is the main agenda. REFERENCES Dekker, M. A. C., & Etalle, S. (2007). Audit-based access control for electronic health records.Electronic Notes in Theoretical Computer Science,168, 221-236. Hoffman, S., & Podgurski, A. (2007). Securing the HIPAA security rule. Journal of Internet Law, Spring, 06-26. Garrison, C. P., & Guy Posey, O. (2012). MEDICAL IDENTITY THEFT: CONSEQUENCES, FREQUENCY, AND THE IMPLICATION OF ELECTRONIC HEALTH RECORDS AND DATA BREACHES. International Journal of Social Health Information Management5(11). Gajanayake, R., Iannella, R., & Sahama, T. (2014). Privacy oriented access control for electronic health records. electronic Journal of Health Informatics8(2), 15. Ozair, F. F., Jamshed, N., Sharma, A., & Aggarwal, P. (2015). Ethical issues in electronic health records: A general overview. Perspectives in clinical research6(2), 73.  

June 29th, 2016

Posted In: Apple Configurator, Business, iPhone, Mac OS X, Mac OS X Server, Small Business

Tags: , , , , ,

In all versions of OS X previous to Leopard, access control restrictions were limited to a security model referred to as Discretionary Access Controls (DAC). The most visible form of DAC in OS X is in it’s implementation of the POSIX file-system security model, which establishes identity-based restrictions on an object in the form of a subject’s user or group membership. Similarly Access Control Lists are a form of discretionary control, though they are far more extensible and discrete then the POSIX model. In such models,  newly created objects or processes inherit their access rights based upon those of the creating subject, so that any spawned objects are not granted access rights beyond that of their creating subject. The key idea behind the DAC model is that the security of an object is left to the discretion of the object’s owner; an object’s owner has the ability to assign varying levels of access control to that object within the confines of the DAC implementation. The DAC model has for decades been a staple in the management of both object/process creation and access across all mainstream computer systems due to it’s user-centric nature. However there is a persistent caveat in these implementations;  in all mainstream implementations of such models, there exists a superuser which has the capabilities to completely bypass access restrictions placed on objects. In POSIX-based Operating Systems such as Unix, Linux, or OS X, this superuser exists in the form of the root user. The existence of such a loophole presents a bit of a paradox. On one hand, it introduces several obvious security ramifications by providing capabilities to completely bypass the DAC model all together; any processes which are invoked by the superuser inherit the “god mode” access controls, they have free reign over the entire system. At the same time, the existence of the superuser account becomes a vital tool for the practical administration of data objects and system resources. In a perfect world, this wouldn’t necessarily be a bad thing. Unfortunately that’s not the world we live in, and it is not uncommon to hear about processes being hijacked for ill-will. If the compromised process has been invoked by the superuser, then the entire system has been compromised, including all user data with it.  With 10.5 Leopard, Apple has introduced a new low-level access control model into their OS, based upon the mandatory access control (MAC) model. Conceptually, the MAC system implements restrictions based upon actors, objects, and actions. In such a system, the actor typically assumes the form of a process, thread, or socket. The object can be any type of resource, such as a file, directory, socket, or even a TCP/UDP network port, among others. The action is simply the request of the actor to be applied to the respective object, and varies depending on the type of object involved in the request. Referring back to the file system model; the actor would be a word processor, the object would be a .txt flat file, and the action would be a call to either read to or write to that text file. When the actor requests access to the object, the MAC authorization system evaluates security policies and decides whether the request can proceed, or if it should be prohibited. In a pure MAC model, the object or process ownership is not generally a consideration; individual users do not have the ability to override defined policy.  Leopard enforces the MAC model via a new framework, architected from TrustedBSD’s MAC framework. This framework introduces “sandbox” access control capabilities which allow a developer or user to apply access control policies to a process, restricting privileges to various specified system resources. The restrictions are generally enforced upon acquisition, so any active file descriptors would not be immediately affected by any policy changes, however, any new open() operations would be subject to the new restrictions. In a fashion similar to the DAC model, new processes and forks will inherit the access restrictions of their parent. In Leopard, these restriction policies can be pre-compiled into any given program, or they can be applied to any executable at runtime.  While Leopard’s MAC framework is based off of TrustedBSD’s,  it’s implementation deploys only a subset of control points provided by the TrustedBSD implementation. Noticeably absent are the majority of the Security Policy Modules available for TrustedBSD and FreeBSD implementations, such as Biba, MLS, or NSA’s FLASK/TE (implemented in SEDarwin), though perhaps some day we’ll see some of these ported to Leopard’s MAC framework.  For now, Apple has offered their own Security Policy Module dubbed “Seatbelt”, which is implemented as a KEXT installed at /System/Library/Extensions/seatbelt.kext.  As of 10.5.2, the feature set of Seatbelt seems to be very much in flux. The only documented way to apply these controls in code is via the sandbox_init() function. Utilizing this function in code provides a way for an application programmer to voluntarily restrict access privileges in a running program. sandbox_init() is very limited at this point, providing only 5 pre-defined constants:  • kSBXProfileNoInternet  – disables TCP/IP networking. • kSBXProfileNoNetwork – disables all sockets-based networking • kSBXProfileNoWrite – disables write access to all filesystem objects • kSBXProfileNoWriteExceptTemporary – disables write access to filesystem objects except /var/tmp and `getconf DARWIN_USER_TEMP_DIR` • kSBXProfilePureComputation – all OS services are restricted An application can utilize one of these constants to restrict capabilities in spawned processes or threads, minimizing the potential damage that can occur in the event that the process is compromised. Figure 1 shows an example implementation of the kSBXProfileNoWrite profile in code: Figure 1. #include  #include  #include  #include int main() { int sb, fh; char **errbuf; char rtxt[255]; char wtxt[255] = “Sandboxed you aren’tnn”; // init our sandbox, if we don’t return 0 then there’s a problem sb = sandbox_init(kSBXProfileNoWrite, SANDBOX_NAMED, errbuf); if ( sb != 0 ) {         printf(”Sandbox failedn”); return sb; }; fh = open(”test.txt”, O_RDONLY); if ( fh == -1 ) { perror(”Read failed”); } else { read(fh, rtxt, 255); close(fh); printf(”FileContents:n %sn”, rtxt);  }; fh = open(”test.txt”, O_RDWR | O_CREAT, 0000644); if ( fh == -1 ) { perror(”Write Failed”); } else { write(fh, wtxt, strlen(wtxt)); close(fh); printf(”Successfully wrote file!n”); } return 0; }     Compiling and running this code returns the following results: % ./sandBoxTest FileContents:  hello               Write Failed: Operation not permitted So, even though our POSIX permissions allows for read/write access to the file, the sandbox prevents it, regardless of user. Running the program even with root privileges yields the same results.  Currently, the options provided by Apple are very all-or-nothing, particularly in the area of file system restrictions. In this way, Seatbelt acts more as a clumsy broadsword, lopping off functionality in large chunks at a time for the sake of security. In this form, Seatbelt has minimized use outside of very vertical applications or the increasingly rare applications that don’t utilize network communication in one way or another. Though these limitations will significantly limit widespread adoption, I believe it would be a mistake for a developer to shrug off Seatbelt as a whole. Luckily, Seatbelt has an alternate application, though currently it is not officially supported. As I mentioned earlier, it is possible to apply sandbox restrictions to any pre-complied executable at runtime. This is done via the sandbox-exec binary, and uses predefined profiles housed at /usr/share/sandbox which provide for fine-grained control of resources. These profiles use a combination of allow/deny rules in combination with regular expressions to specify system resource access. There are numerous control points, such as network sockets, signals, sysctl variables, forking abilities, and process execution, most of which can be tuned with fairly decent precision by utilizing a combination of regex and static inclusion sets. Filesystem objects and processes are identified via POSIX paths; there currently is no target validation performed ether via checksums or digital signing.   Figure 2 shows a sample sandbox profile that can be applied to restrict an application from making outbound communications and restricts file system writes to temporary directories and the user’s preferences folder. The ‘debug deny’ line tells seatbelt to log all policy violations. This proves to be very useful in determining filesystem and network activity by an untrusted program. It facilitates a quick-and-easy way to do basic forensic testing on any program acquired from an untrusted source. Figure 3 shows example log violations of a network-outbound violation, and of a file-write violation, respectively. To apply a sandbox profile to a standard application bundle you must pass sandbox-exec the path of the mach-o binary file which is typically located in ‘Contents/MacOS/’, relative to the application’s bundle. You can specify a sandbox profile by name using the -n flag if the profile resides in /usr/share/sandbox, or you can specify a full path to a profile with the -f argument. Carbon applications may require the LaunchCFMApp wrapper to properly execute. See figure 4 for example syntax for both Cocoa and Carbon Applications. Figure 2. Example sandbox profile (version 1) (debug deny) (allow default) (allow process*) (deny network-outbound) (allow file-read-data file-read-metadata   (regex "^/.*")) (deny file-write*         (regex "^/.*")) (allow file-write*         (regex "^/Users/johndoe/Library/Preferences.*")) (allow file-write* file-read-data file-read-metadata   (regex "^(/private)?/tmp/")) (import "bsd.sb")     Figure 3. Example log entries from TCP and filesystem write violations 3/4/08 12:15:10 AM kernel dig 79302 NET_OUTBOUND DENY l= unavailable r= 4.2.2.2/domain UDP 1 (seatbelt)  3/4/08 12:43:05 AM kernel sh 79147 FS_WRITE_DATA SBF /Users/Shared/test.txt 13 (seatbelt)  Figure 4. Using launchd to sandbox cocoa and carbon applications.   Cocoa % sandbox-exec -n localonly /Applications/TextEdit.app/Contents/MacOS/TextEdit Carbon % sandbox-exec -n localonly /System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp /Applications/Microsoft Office 2004/Microsoft Word Unfortunately, the system seems to be far from finalized, and even some example profiles provided by Apple do not seem to be completely functional, or contain unimplemented control points. One example of this is seen when trying to implement IP-based network restrictions. Apple provides example entries for layer3 filtering in the included profiles, but they are commented-out and illicit a syntax error when ran. Additionally, Apple has a rather ominous warning in each of it’s provided profiles, stating that current profiles are deemed to be Apple System Private Interfaces, and may change at any time. However, that’s no reason to completely ignore the technology. Given what has currently been implemented, and taking into consideration control points which are alluded to by Apple’s own imbedded comments, Seatbelt is showing significant promise to provide very fine-grained resource access capabilities. By utilizing these restrictions, applications and users can ensure that even in a worst-case scenario, possibilities for errant/hijacked process damage becomes mitigated and compartmentalized. There are many real-world situations where this type of access control model fits very well, particularly in complement to standard DAC systems: they can be used to mitigate privilege escalation opportunities for shell users, to confine behavior conformance of processes to defined resources (and there by protect against hacked processes), or as a forensic tool to determine software malfeasance. By providing these type of capabilities through the Seatbelt policy module, and by providing a path towards implementing more complex MAC policy modules, Leopard’s new MAC framework ushers in a new level of security and access control capabilities for OS X.

May 22nd, 2008

Posted In: Articles and Books, Mac Security

Tags: , , ,