Convener: Rupa D.
Notetaker: Kelley N.
- Article ÂNo Silver BulletÂ by Fred Brooks
- Book Secure Coding: Principles and Practices by Wyk and Graff
- Kali Linux
URLÂs and other Links, Books, Organizations, Articles etc:
- cheat sheets Â https://www.owasp.org/index.php/Cheat_sheets
Notes and/or 3-5 key points discussed:
A lot of people don’t realize how vast the security field is, what opportunities there are within it, orÂ what resources are available in the event of a security incident. This talk will not cover everything, just the basics.
- Slide: Agenda:
- No silver bullet
- Software problems and possible solutions
- Does your code have vulnerabilities?
- Kali Linux
- Security controls
No Silver Bullet: book by Fred Brooks (of The Mythical Man Month) A highly recommended book for getting to know the field.
Complexity: These are inherent issues with software, and exclusive to software. These are why it’s difficult to ??? software, or even manage it. No two software problems are the same. If you write a certain program to solve a problem, then write the same program two weeks or even two hours later, it will be different. The vast number of possible and existing programs and their hardware, especially their interaction, creates a complexity problem. It’s next to impossible to model a software situation to solve a problem.
Conformity (i.e. compliance) No matter what kind of software you write, at some point it mustÂ interface with other software and hardware. It must conform to another person’s idea of how software should be.
Changeability: the entire situation described above is in flux, in addition to its existing complexity.
Invisibility: it’s hard to see what’s going in inside a system of software.
Buy vs. build: easier to build things yourself. You can farm out a lot of the pieces of a software system.
Off the shelf: faster, cheaper, documentation exists. In the 70s and 80s, it was much
But does it satisfy my requirements? <missed>
Requirements and rapid prototyping (reqs are the hardest part)
Great designers are of prime importance
intrinsic (according to Brooks)
Does your code have vulnerabilities? Cannot be taught, is an intrinsic talent Âgood designers can be taught, great design is business culture rewards great managers, but not great designers. Identify, reward, and Scan it!! there are a lot of great tools out there. Network vulnerabilities: nmap, Core Impactr, OpenVAS, Burp, etcv
Code review is integral. Secure Coding Â book published a few years ago
Penetration testing Â a very lucrative area. Protocols, passwords, ciphers, multi-factor
authentication, race conditions, etc Kali Linux is specifically tailored for this. Information is readily available.
Static analysis: CodeSearchDiggity (Google open source), Valgrind, Security Advisor (Coverity),
Source Code Analysis (HP)
It’s a good idea to do at least some of this before you do your code review 🙂
(Suggestion from attendee Alison: clang. Finds warnings that gcc doesn’t.)
Kali Linux (adv. Users) Linux OS based on Debian with penetration testing tools.
Specifically targeted for the security community
Not for regular consumption
Excellent documentation, kalilinux.org
Network services disabled by default including bluetooth
Single user mode with root access by default
Can be run on a Raspberry Pi
Tagline is ÂThe quieter you become, the more you can hearÂ
Secure configurations for hardware and software on mobile devices, laptops, workstations, and servers
Application software security Â mostly for webdev. Secure for the various different types of attacks wireless device control Make sure you don’t use too much Bluetooth Boundary defense. Have firewalls installed with the right rules.
Penetration testing (pentest) mimics the activities of attackers. Red team exercises are one level above this. For example, they make sure no one can just walk into a mobile device factory and tweet from whatever they can find. Red teams will go into shops, ask the developers what they are doing in terms of security, etc, then prepare a report for the shop as to what they need to do to become more security minded and incorporate security into the development process.
There are at least 20 categories. These four are a subset.
Always use antivirus, no matter what you’re doing! Recommends for avast, ???
Story from an attendee about hearing suspicious hard disk movement, reporting it, the team took it seriously and found malware in the company system.
Question from attendee about how to get involved: go to owasp.org. There are open source projects available, and the staff will work with you. As a student, start by reading the Secure Coding book.
Once you see the code, you will know how to exploit it. The tools change, the principles don’t.
Recommend from attendee to read: Code Complete (book), attend DefCon,
Discussion of Defcon: it’s strange to hear discussion of horrible security situations; there is a contingent of attendees who are against women being there, and they will put pressure on female attendees so be with someone who will protect you and stay with the right people so you will not be targeted, RSACon is m;ore product oriented; go with high ranking trustworthy males so that you are not mistaken for a booth babe. Comment from an attendee who had a good experience. Suggestion from another attendee for women to group together at DefCon.
If you go into security as a career, you will be dealing with these people in the course of your work.Â dc650 and dc408.
Discussion of how to help women be safer at conferences, how to respond to and deal with problematic men, and where to continue the discussion on DevChix.
Reminder that there are a lot of wonderful men who will support you.