Richard J. Bocchinfuso

"Be yourself; everyone else is already taken." – Oscar Wilde

FIT MGT5114 – Wk2 Discussion 1 Post


Is unexpected behavior in a computer program necessarily a vulnerability? Why or why not?


According to Pfleeger, Pfleeger & Margulies (2015), programming flaws can cause integrity problems which lead to harmful output or action, and these programming flaws offer an opportunity for exploitation by a malicious actor (p. 162). Agreed, but I believe the question is, does this imply that unexpected behavior is always a function of a programming flaw and if there is a programming flaw, has it created a vulnerability which can be exploited? I think this is a hard question to answer without a deeper more refined definition of “unexpected behavior”. I am sure many remember the first Basic program they every wrote, something like:

10 print “Name”
20 goto 10

The addition of a trailing semi-colon and spaces between Name and the trailing quote on line ten (10 print “Name     “;) will alter the output, ten trailing spaces produce output that is different from twenty trailing spaces, and while the behavior may be unexpected, it does not indicate a vulnerability.

Most modern programming languages have constructs to trap exceptions. Constructs like the try/catch/ finally attempt to trap exceptions and hopefully exit the condition gracefully logging the error.

try {
execute code }
catch (error) {
log error if try thows an execption }
finally {

Many modern applications leverage these constructs, but it’s certainly possible to deliver working code which contains no exception handling at all. There is an abundance of code in the wild that is highly vulnerable for a myriad of reason, ranging from bad programming to situations that were never considered and thus not addressed. Legacy systems like programmable logic controllers (PLCs) running code from a time when the world was not connected, and security was not a concern contain some serious vulnerabilities.

Agile and DevOps movements have dramatically accelerated the frequency of software releases. It’s common practice to release software containing known and/or documented defects which are identified during testing cycles but not flagged as show stoppers, meaning the release cycle continues. These defects are not vulnerabilities but rather known bugs, typically with documented workarounds, essentially nondesirable expected behavior rather than unexpected behavior. Shorter release cycles are accompanied by an increase in unexpected behavior and offset by rigorous version control, A/B testing and automation which automates the rollback to known good system. Systems fail faster today, and rollbacks happen even more quickly. There is irony here, systems which have life or death implications have slow (very slow) release cycles (e.g. – it’s hard to do frequent software releases and tolerate known defects when talking about the heart-lung machine). These systems tend to be arcane and often vulnerable because they were never architected to live in the connected world, they value predictability and stability over functionality.

Exception handling along with verbose logging and the creation of audit trails have become standard practices. In the days of top-down systems is was easy for the developer to own the user experience but the dawn of event-driven made this much harder and logging is now a critical aspect of every system. The focus of many security firms is no longer to keep those exploiting vulnerabilities out but rather to keep them in, find them and determine what they are trying to do (


A New Avenue of Attack: Event-driven system vulnerabilities. (n.d.). Retrieved March 15, 2017, from

Error Handling. (n.d.). Retrieved March 15, 2017, from

Manifesto for Agile Software Development. (n.d.). Retrieved March 15, 2017, from

Pfleeger, C. P., Pfleeger, S. L., & Margulies, J. (2015). Security in computing (5th ed.). Upper Saddle River: Prentice Hall.

Press, A. (2016, August 12). Keeping hackers out no longer the best security strategy, FireEye says. Retrieved March 15, 2017, from

FIT MGT5114 – Wk1 Discussion 2 Peer Response

I enjoyed reading your post. Many hobbyist black hat hackers and script kiddies are pretty lazy. I understand the concept of never connecting to a Starbucks WiFi to avoid a man-in-the-middle (MitM) attack it probably a bit unreasonable. Security is often like locking the front door of our home or our car door when we leave it unattended, and these are merely deterrents because most thieves are pretty lazy, they will walk around the mall pulling door handles until one opens so the deterrent is quite effective. The same idea often applies to network security, if we use something like a VPN to encrypt communication while far from unhackable it’s likely enough to have the individual perpetrating the man-in-the-middle attack pass over us and look for easier prey. In a world where our lives are conducted online, my personal philosophy is to lock the door of the house, and the car when I leave it unattended but never leaving the house or the car unattended is probably unreasonable.

If you’ve never seen how easy it is to conduct a MitM attack here is a good instructional video ( that shows how to use the WiFi Pineapple to carry out a MitM attack. Scary simple. 🙂 It’s much harder to crack the encrypted captured data so if someone is sitting at a Starbucks with a WiFi Pinnable conducting a MitM attack with either a rogue access point or by spoofing an access point (evil twin AP) the probability of the perpetrator spending the time to decrypt the data is low. A MitM attacker will likely move on to someone else who is passing unencrypted traffic.


Pfleeger, C. P., Pfleeger, S. L., & Margulies, J. (2015). Security in computing (5th ed.). Upper Saddle River: Prentice Hall.

FIT MGT5114 – Wk1 Discussion 1 Peer Response

I enjoyed reading your post. Long, complex passwords have become an essential security measure. I am an aspiring ethical hacker, and one of my hobbies is cracking hashed passwords. Ten years ago cracking a nine character upper and lower case alphanumeric password would have been highly improbable. Today you can grab an AWS p2.16xlarge instance for about fourteen dollars an hour for an on-demand instance and if your frugal and looking to crack passwords at scale you could use spot instances and lower the cost for a p2.16xlarge to < seven dollars an hour. The use of GPUs has lowered the time to crack password from years to days and from days to minutes and seconds. Most people know that using a long alphanumeric password which contains upper and lowercase letters, numbers and special characters is a good idea. It’s a good idea to avoid simple leet passwords like “H0use” because these sort of passwords provide little int the way of extra security. A little know fact is that the ability to use of a “:” in your password makes it significantly harder to crack, the reason is that password cracking tools like hashcat use the colon as a delimiter (the colon delimiter is linked to the Unix \etc\passwd file use of the colon to delimit fields) for the split function, so a colon confuses the password cracker. Unfortunately, the colon is a common delimiter, and not all systems will allow its use.


Amazon EC2 – P2 Instances. (n.d.). Retrieved March 12, 2017, from

Dan Goodin – May 28, 2013 1:00 am UTC. (2013, May 27). Anatomy of a hack: How crackers ransack passwords like “qeadzcwrsfxv1331”. Retrieved March 12, 2017, from

Gite, V. (2015, August 03). Understanding \etc\passwd File Format. Retrieved March 12, 2017, from

GPU Password Cracking – Bruteforceing a Windows Password Using a Graphic Card. (2011, July 12). Retrieved March 12, 2017, from

Hashcat advanced password recovery. (n.d.). Retrieved March 12, 2017, from

Mathiopoulos, I. (2016, October 05). Running hashcat in Amazon’s AWS new 16 GPU p2.16xlarge instance. Retrieved March 12, 2017, from

Pfleeger, C. P., Pfleeger, S. L., & Margulies, J. (2015). Security in computing (5th ed.). Upper Saddle River: Prentice Hall.

Project 12: Cracking Linux Password Hashes with Hashcat (15 pts.). (n.d.). Retrieved March 12, 2017, from

Spot Bid Advisor. (n.d.). Retrieved March 12, 2017, from

FIT MGT5114 – Wk1 Discussion 2 Post


Why should you periodically change the key used to encrypt messages? What attack is more likely to succeed if a key has been used frequently? How frequently should the key be changed?


While breaking modern day encryption keys (e.g. – AES-256, RSA-1024, RSA-2048, RSA-4096) is improbable it is not impossible.  Many enterprise-class encryption systems leverage key management systems so that encryption key rotation can be accomplished without the massive burden of having to maintain and track the key pairs manually.  One such solution is keyAutority from Thales.  Key management systems are often used for encrypting data-at-rest on disk and tape.  As we learned in chapter two of the text, the initial exchange of keys is subject to a man-in-the-middle attack, but more importantly, it’s if a single key pair is used, the lack of a key rotation policy could and has created serious exposure.  In a word where developers are moving at an unprecedented pace, and cloud computing is providing easy access to infrastructure for developers, we are seeing all sorts of human error which is creating severe pain for many organization.  Most notably developers are publishing keys to GitHub and hackers are now crawling GitHub looking for AWS keys (the code to perform the crawling has even been published to GitHub).  AWS is a giant honeypot sitting on the internet and human error like publishing AWS keys to GitHub is a huge risk, a key management strategy is really important to ensuring that if a key gets into the wild you can minimize the potential impact.

The governance of how often an encryption key should be changed really depends on what the encryption key is used for.  IMO the complexity of key management and the value of the assets being protected need to be taken into consideration before deciding on a key management strategy.  Additionally, compliance with regulatory agencies needs to be considered when developing a key management strategy, compliance with regulations like and SEC 17a-4 and HIPPA are likely to seriously influence key management policies.


6 Jan 2015 at 13:02, Darren Pauli tweet_btn(). (n.d.). Dev put AWS keys on Github. Then BAD THINGS happened. Retrieved March 08, 2017, from

Burton, H. (2017, January 10). TruffleHog: Hacker publishes secret key spotter to Github. Retrieved March 8, 2017, from

Mimoso, M. (2014, June 19). Hacker Puts Hosting Service Code Spaces Out of Business. Retrieved March 08, 2017, from

Pal, K. (2015, July 15). 10 Best Practices for Encryption Key Management and Data Security. Retrieved March 08, 2017, from

Pfleeger, C. P., Pfleeger, S. L., & Margulies, J. (2015). Security in computing (5th ed.). Upper Saddle River: Prentice Hall.

Townsend, P. (n.d.). HIPAA/HITECH Act – Encryption and Key Management Requirements. Retrieved March 08, 2017, from

FIT MGT5114 – Wk1 Discussion 1 Post


Do you currently use, or have you used in the past, any computer security measures? If so, what do you use? If not, what measures would you consider using? What attacks are you trying to protect against?


I have been in the technology field for 25 years, a large portion of that time as a storage architect and software developer. I use technologies like firewalls (Cisco ASA, Palo Alto Networks, and tons of open source solutions like iptables, pfsense, monowall, smoothwall, opnsense, etc…) to secure external services, locking services down to allowed IP ranges and in some case specific origin IP addresses, opening specific protocols and ports, NATing, proxying and reverse-proxying traffic (NGINX) all in an effort to obfuscate and reduce the attack surface. I use protocols like ssh and sftp to encrypt communication between client and servers. I use MD5 hashes to quickly validate binaries (and other files) to ensure that the files have not been tampered with. I use more obscure technologies like port knocking to programmatically secure ports when they need to be exposed but establishing a VPN connection is overly cumbersome. I use NIDS (network intrusion detection systems) like Snort in combination with the ELK stack to gather data and perform analytics to identify threats. I use RSA keys and multi-factor authentication (MFA) every day for everything from ssh access using key pairs instead of password authentication to IPSec and OpenVPN VPN connections which require multi-factor authentication via RSA tokens, Google Authenticator, Duo, etc… I also use AES-256 encryption data-at-rest-encryption (D@RE) technologies, RAID and erasure coding which all protect data at rest.

I also use so many of the tools found on this site:  on a routine basis. I use Nmap and Wireshark almost daily for network and protocol analysis. I also routinely run scheduled vulnerability tests using a subscription service from Beyond Security to identify and alert on vulnerabilities on public facing web servers.  All of my Linux servers run Lynis daily to evaluate their security posture and publish reports which are sent to a system which parses the reports and produces an exception report which is distributed outlining any required remediation. I also am an aspiring ethical hacker who frequently uses Kali Linux and Pentoo Linux depending on what I am trying to do, Kali Linux is my go to, but Pentoo is nice for RF hacking. I am an avid watcher of Hak5, reader, and listener of 2600 and have been for many, many years.  I am the proud owner of a WiFi Pineapple, many homemade antennas, the USB Rubber Ducky and the HackRF One. 🙂

I am just scratching the surface here; it seems like I could go on forever but hopefully, this provides a reasonable level of detail and insight. Oh yeah, I use Anti-Virus (AV) software for that false sense of security but mostly just to slow my Windows desktop down. 🙂

Here are some of my objectives:

  1. Identify vulnerabilities and remediate before the bad guys do.
  2. Reduce my attack surface as much as possible.  Don’t want to be a honeypot on the internet, no point in enticing a script kiddie to target me. For instance, don’t allow your publicly accessible server to respond to ICMP so that when your neighbors inquisitive kid does a subnet scan he decides to target you, if you’re gonna stick a server directly on the internet and allow ssh don’t use port 22, don’t ever use WEP on your WiFi access point, etc… etc…
  3. I love to learn and research things (hence why I own a WiFi Pineapple, Rubber Ducky, HackRF One, etc…).  The more I know the better I can protect my assets.

Since this is a security class, I’ll leave you with one of my favorite websites:


Pfleeger, C. P., Pfleeger, S. L., & Margulies, J. (2015). Security in computing (5th ed.). Upper Saddle River: Prentice Hall.