Security Ripcord


Considerations for an Information Assurance Laboratory

September 21st, 2007 cutaway Posted in Education, Hacking, Patch Management, Penetration Testing, SANS, Security 1 Comment »

I find it interesting what professors will say and do when it comes to providing an educational experience to their students. On one hand I can understand that the professor is trying to discover the best way possible to quickly train their students about a specific topic. On the other hand I am concerned about the, at times, lack of intelligent thought process on how it is going to affect other students, faculty and staff that also use and maintain the same resources and network environment.

One of these situations arose in my organization the other day. A college is in the processes of providing computer security courses that will train the students in subjects such as risk assessment, programming, networking, and defensive and offensive tactics (to name a few). Because it is a new program the college faculty and staff are still gathering resources, deploying them in labs, and creating the teaching platforms. All of this while the courses are being taught.

When the college decided to start providing the students with this type of course work they did approach the university’s networking team to let them know what was happening. After a few meetings it was determined that it was necessary to operate any labs that would be doing offensive tactics from a lab that was completely isolated from the university network as well as the Internet. Although very good in theory, completely isolating a network in this manner really brings forward some interesting problems. Problems that require a lot of planning, coordination, work and money.

The following is a list of a few things that should be taken into consideration as you are developing security courseware.

1. Because of the types of network and other computer activities associated with information security the details on any lab deployments must be handled just like any other system development and bringing together all of the people and organizations involved and follow a life cycle. By doing this you will determine issues and identify problem areas in the design phase and before classes start. As with any system design, it is much harder to change or address issues during production. The whole “fixing the plane while it is flying” issue.

2. Labs that will be conducting offensive operations or monitoring must be completely isolated from the school’s network and the Internet. There are many reasons for this.

  • Network traffic will contain plain text personal information related to other students, faculty, and staff. I used the gmail attack tools developed by Robert Graham and presented at DefCon 15 as an example to drive this point home.
  • Student attack tool activities are hard to distinguish from malicious attack tool activities. Many tools are designed this way to avoid network and other protections.
  • Being convicted, or even just accused, of hacking a resource without permission could ruin the career of the student and any teachers involved with the incident. Each student is trying to learn and grow. The majority of them are youths who want to test their boundaries and skill levels. Sometimes the temptation is just too much, not to mention the potential for improper configuration, and they might scan or attempt to exploit a vulnerability. The school administrators and teachers must help protect their students from this.
  • The reputation of a school is involved. If the school’s students and professors are accused of attempting to hack computers connected to the Internet then the school is going to see a serious reduction in the amount of students attending the security courses and the rest of the school’s curriculum.

3. When you are building your labs be sure to take into considerations that students operating on an isolated network are still going to need access to the Internet. They will need this to obtain tools, read manuals and howtos, and interact with their Facebook/MySpace accounts. Although having a few computers off to one side is a good quick fix, it is not the optimal situation and you will be reading complaints about this in the class evaluations. Perhaps a better solution is to have dual input monitors that can be quickly switched back and forth by the students. Each system should have different backgrounds or operating systems so that the students are aware which system they are using. Considering thin clients is also a viable solution and would prevent network cables from being swapped around.

4. Create separate networks for security classes and regular classes. Nothing is more frustrating for a student or a teacher to come to a lab they have been working on most of the semester only to find that somebody has modified its configuration or hacked their resources. This is detrimental to the learning experience and will lead to finger pointing and bad blood.

5. Create update serves that can be a repository for OS and application patches. With properly document procedures these servers can be kept on the campus’ main network in order to retrieve updates via the Internet and then reconfigured to provide service to the isolated network. Updating in this manner is a great learning experience for the students and will prepare them better for real world experiences.

6. Start a tool repository to version control tools. Many tools change rapidly and also disappear. Maintaining this repository is a good way to show students product evolution. It is also a good way to monitor these for malicious activity. This helps keep developers honest. Let’s face it, eventually some tool will be updated with malicious intent. It is only a matter of time, and think of the publicity your school will get if you are the first to identify it.

7. Network isolation is a common practice in the security research field. Ed Skoudis developed his SANS GCIH class to be an isolated environment. The SANS Integrated Cyber Exercise (ICE) is conducted in an isolated environment. And the RootWars at Learn Security Online are conducted in an isolated environment. It can be done but it requires planning.

8. Finally, listen to and leverage the experience of the information security professionals within your organization. Teaching security courseware is one thing, but working as a security professional is completely different. There are different goals and different mindsets. If the information security professionals within your organization are good they will get you what you need while also maintaining an acceptable level of security for the entire organization.

Remember, you are training the future information security professionals of the world. You should show them that security is necessary as well as implementable. Circumventing a schools security and infrastructure policies and procedures just to provide additional or “real world training” to the students is not setting a good example. It is, in fact, sending the wrong message.

If you have any additional concerns or recommendations, please leave a comment sot that others can take it into consideration.

Go forth and do good things,
Cutaway

Technorati Tags , , , , , , ,

The Next Phase in Patching

September 20th, 2007 cutaway Posted in Apple, Microsoft, Patch Management 2 Comments »

Recent hardware and software problems got me thinking about patch management. Some companies have a handle on this effort. SMBs, SOHOs, and home users, however, are a bit more challenged because of funds and skill levels. The software manufacturers haven’t made it very easy either. Let’s list out the overall problem.

1. Vulnerabilities in software and drivers put computers and users at risk. The mitigation for this is to patch the software and driver whenever there is an update and especially when there is a security update.

2. Most software do have automatic update features. They can poll on bootup or when the program starts. They can be configured to run at granular start times or stopped completely. Unfortunately, there is not really a standard where to place this information and there is no way to determine when other softwares are scheduled to update unless you specifically open that piece of software and record the scheduled update time.

3. Drivers are more difficult to keep up with than other software. Users do not usually directly interact with drivers and most do not have an automatic update scheduler to determine if an update is available. Although some OSes handle this for some drivers they do not do it for all.

4. The more confusing and time consuming a process the less likely end users are going to perform the task. Most systems are vulnerable because people do not know how to update or just don’t want to take the extra time necessary to go through and configure automatic updates or monitor specific drivers that do not include the service. And, if the automatic update affects their user experience they are going to find a way to turn that feature off.

Here is my solution: Microsoft needs to come up with a Central Update Console that software and driver developers can hook to configure automatic updates. They already provide this type of feature through the “Add/Remove Programs” console. Good developers utilize this to help users and administrators manage the software that is installed on their systems. How hard would it be to come up with a solution that other developers could hook to help with centralizing the management of updates and provide a significant positive impact on the overall security of every computer on the Interweb? Although the design, development, testing, implementation, and maintenance of this project would be challenging, I am willing to be that this would be a small project in the grand scheme of Microsoft OS development. They don’t need to take every software vendor into consideration, they just need to come up with one method all of them could use. Once a system is developed software developers can start modifying their products to hook the console. They wouldn’t need to take out their current auto-update mechanism, rather, they could leave it in place. This is how the “Add/Remove Programs” console works. Software developers have not removed the mechanism to uninstall from their software, rather, they have placed hooks in the “Add/Remove Programs” console that calls their uninstall and repair mechanism. Users and admins who prefer a particular method are all satisfied.

Finally, it is not like this is not done other places. Linux in particular, and to a smaller context Apple, has been doing this for a while. Most distros have a packaging system the allows developers to centralize the patch management and automatic updates. End users and admins only have to worry about watching for updates to software that they have installed outside that packaging system. Very nice, very ease, very secure.

So, how about it Microsoft? Don’t you think that this would benefit everybody? It certainly could not hurt.

Go forth and do good things,
Cutaway

Technorati Tags , , , , , ,