Useful Links
|
Sunday, December 21. 2014
Sony Hack, and technical limitations ... Posted by Jason Robertson
in Information Technology, Security at
11:51
Last modified on 2014-12-28 13:42
Sony Hack, and technical limitations that make it easier for these to occur.Over the years, there has been many attacks and compromises of various networks, some of these are from internal attacks, others are from external agents. Many of these attacks are in the form of attempting to gain access to an account with high enough access to give them privileges to gain access to services they require for their purposes. In the case of Sony they were after their internal data. In these cases the enemy agents, their main goal is to gain an account with Administrative priviledges, because these accounts give unfettered access to not just a single system but multiple system, and all the data on those systems. These may include, but not limited to the workstations, servers, file servers. And in the case of Windows based systems, this could give access to even Workstations and Servers that are encrypted with Microsoft's Encrypted File System. This single all powerful account permission, gives a single attack target, and with this ability being remotely accessible it makes this an ideal target. This account alone can not only gain access to the important information, but in some cases even hide the existance of the attack. So how could this be fixed? People may believe that this cannot be fixed, but this risk can be greatly reduced, since many attacks that are not from "inside threats", occur through phishing attacks, the simplest method is to simply seperate the users account from their administration accounts, with this change it makes it more difficult from providing unfettered access. An added level of security would to provide seperate machines for administration and day to day usage, this limits the attack plane. But either method, requires that these administrative accounts should have the least level permissions to do their job. A better solution though it would require a great deal more configuration, and possibly functional changes with the various operating systems, is to build a system based on Privilege seperation, each administrative account will have limited access, and cannot view or access functions outside of it's mandate. So a user administration account, could manipulate the users account information, and provide privilege access to below this accounts privilege levels of this account, but would not have access to the file system. The filesystem administration account would be totally unaware of detailed user information, and could not modify or user information, and would not have access to the account passwords. Services administrator account, would give access to required file, network, and other services required to start and run the service. The main Administrator account can only modify, create, delete the privilege administrator accounts. Priviledge seperation would provide, a greater level of security by limiting what an administrator account can do, especially if the true administrator account is only accessible from a trusted interface, this would completely limit what can be done by any of the administrator accounts, and almost completely limit unauthorized accounts or accounts receiving unauthorized permissions. Saturday, December 20. 2014
Proposed new SSL/TLS Standard Posted by Jason Robertson
in Information Technology, Security at
13:35
Last modified on 2014-12-20 18:39
Proposed new SSL/TLS StandardProblemSSL and TLS standards all have a major weakness, trust is linear. The certificate your server is signed by one organization, that certificate is either signed by one of their own keys, or by the the key for the same certificate. This can lead to one of the security risks if someone can compromise or falsify one of the signing keys of the trust relationships. Once this trust relationship is compromised, the attacker may use this for countless actions. Continue reading "Proposed new SSL/TLS Standard"Monday, December 15. 2014
Security Site Changes Posted by Jason Robertson
in Security, Site Changes at
23:14
Last modified on 2014-12-16 00:06
Security Site ChangesCurrently on SSLabs this site has an A+ Rating, but with this rating the level of support for older web browsers has been reduced. As of this change, IE on XP is not supported, but you should be updating XP anyways. SSL2 and SSL3 has been fully disabled. TLS1.0 is on my list to disable Continue reading "Security Site Changes"Monday, July 21. 2014
My opinions on the OpenSSL Roadmap Posted by Jason Robertson
in General Ramblings, Security at
09:43
Last modified on 2014-08-02 10:53
My opinions on the OpenSSL RoadmapSo OpenSSL has released their Project Roadmap, to many this seems to be a push in the right direction after many notable vulnerabilities in the past, which has caused at least to forks to be created. I have noted in the past, many issues with the OpenSSL code base, which has finally been brought to light, these consist of a constantly changing API, poor or non-existant documentation, complexity of the code, readability of the code, and the shear number of versions. Changing API The API in a release should never change, for any version of 0.9.8*, they API should be unchanging. Once the version has been released no new features should be added, only security fixes. This reduced the headache of refactoring code when some major change has occurred. API Changes should occur in phases as well, with deprecation of previous functions occuring over a long period, this would allow for updating to newer major versions with little impact to the third party code. Poor or Non-Existant Documentation This is a pretty annoying issue. There is little in the way of useful documentation, this is more of a problem for new users to using OpenSSL, many of these questions aren't answered on the OpenSSL site at all, but are elsewhere, on potentially less reliable or trusted sites. Now some of the questions have been answered, but still not in such a way that a lay-person could easily understand what they are doing, why they are doing it, or the potential risks? These are such questions
These are all very important questions, and not always covered by the developer, but often through third party sources. Mind you, I have noticed more information cropping up in recent months and years. For functional documentation, the POD files generated should be on the website, and documented inline, if it isn't already. Complexity of the Code The OpenSSL code is notoriously, complex to browse through with the multitude of files. Many things should be done to simplify the code tree.
A major thing is that is missing that should be implemented would be Number of Versions This has always been a sticking point for me, there shouldn't be the number of versions on the go as OpenSSL currently has, this creates code complexity, as a change for one might have to be back ported and forward ported to the various releases, right now there's at least 5 in development if not more.
Of these 0.9.8* should have been retired awhile ago. 1.0.0* should be in a stage of critical bug fixes. 1.0.1* should be fixes and usability improvements. 1.0.2* should be still changing, with creating wrappers for the new API to port the old code to using it. and 1.1.0* should be in API flux. |