This is not only the conclusion to this week but also to the semester. During this three months I learnt the following:
Motivation is the key to success, but too much motivation is risky: it might end up in a total lack of interest.
Estimating is hard.
Individual works are faster, but when the person working on this task is not available, things can turn bad. Therefore, people redundancy on tasks is required.
Unit tests are as important as integration tests.
Versioning software is extremely helpful.
Demos may go wrong: always have a local (and even mock) version.
On this week I fixed the HTTPS bug: apparently, there was a problem with our deployment script. This was my main work during the whole week. By the looks of things, we’ll only do one more week of work.
After our demo, I intend to fix the bug with HTTPS certificate and prepare everything for our final delivery. I believe we won’t be doing a fifth sprint (not a whole sprint, maybe one or two weeks).
A couple of days before our demo, we had a small problem with the HTTPS in the broker: something really weird happened with the certificates. Since we had no time to fix it before the demo, we had to do a rollback on the server. Fortunately, the Docker image was versioned correctly and the change required was only a modification in the Kubernetes YAML file. Other than this, our demo was good.
Today we officially delivered the project at the Engineering Expo. There we presented our project to some judges and fellow students. Well, usually the explanation was for the judges, and the students would come just to play the game and try to get through the last level and put their playertag in the leaderboard.
I have to say that my score will be (Or already has been) overcomed by anyone who has a just a fraction of eyes to fingers reaction. What I’m trying to say is that even after one semester of development, I’m so bad at the game… After more than 1 hour playing level 4, I surrendered, and assumed that I could go trought all the levels in 2 hours, more or less, and then I pushed my score to the DB, manually. I think I deserved to be in the leaderboard of the game, even if I couldn’t put it there usiang legal abilities.
But now, onto my kinda semester retrospective.
I feel that overall this smesterI learned a lot about WEB development using NodeJS. In my WEB Development class project I learned about front-end frameworks, back-end development and deployment, different ways to make requests to de server, implementation of MariaDB queries on the server’s routes and the delivery of JWT and local storage.
What I learned in that class was useful for me, so that I shouldn’t need to worry about how to do all of the back-end development on this project, and instead focus on enjoying more the project, setting up Mongoose and MongoDB and designing server tests. I found out that I could really have fun doing those three new things because I didn’t worry at all for the rest of the stuff.
So, why did I asked you to read about the security layers? Because security in depth is based on the layers implementation. We already discussed how layers are supposed to function, if you achieve to cover all holes of each layer with the preceding layers, there will be no way an attack could be successful to your system. The thing is that achieving that level of perfection is impossible. Instead, security in depth assumes from the start that the layer method can, and will eventually fail. The layered security only achieves the exhaustion of the threat (Successful defense) or the slowing of it, giving time for other plans of action and countermeasures initialize.
Depth defense also assumes that the hack or breach isn’t necessarily of remote origin, this means that the possibility of physical theft, threats, unauthorized person access, and some other unique events (See van Eck phreaking below).
Usually, taking into account those possible events involve the set up of:
Monitors, alerts and emergency responses
Authorized personnel activity logs
Forensic analysis
Reports on criminal activity
Disaster recovery
Remeber that the objective of depth defense is to gain time. Each of the set up new components main objective is to delay the threat, which might not be obtained if we used only technological solutions. The obtained extra time should be used by the administrator to identify and try to overcome the hack.
And I guess that is for now regarding security.
As a mini comment
As the 8th blog regarding security, I will talk about the computer security layers. There are some people who state that there are 5, there are some people who say there are 8. What I mostly found during the investigation is that there are security layers as layers in the cake (Including the top frosting), 7.
What you, dear reader, need to remember during the reading of this entry, is that this set of rules can be implemented either by a network system administration or a regular single computer user.
The logic behind the security layers is the following: A single defense will be ineffective or flawed if the defense mechanism leaves unprotected areas, with its protective layer (umbrella), empty. That it’s why the layer’s purpose is to cover those empty spots. Theoretically, the empty areas on each layer would be so different, that an attack can’t penetrate through all the holes, and the service would remain available.
Application Whitelisting: The objective is to install just a set of limited programs and applications in the administered computers. The fewer applications, the fewer possibility there is of a breach.
System Restore Solution: This is one of the most talked security solutions in the classroom. Basically, it consists of creating a plan of action when the hack peril arouses. This would let the user gain access to their files, even if the system is hacked and damaged files remain.
Network authentication: A system of usernames and passwords must be taken into place. This would give access only to authorized users. This means no login without a password prompt.
This entry is not addressed to regular computer users, but more specifically to engineering students or people interested in network’s security, as the concepts are not that regular. This entry’s topic is the security of the network’s enterprise.
Virtual Private Network
This first category isn’t that much complex, as Virtual Private Networks (VPNs), are more and more widely used by the general users. So I won’t be talking a lot about this. VPNs are a method used by enterprises to connect and access an internal network from the outside, using a more secure network and an encrypted one.
Intrusion Detection Systems (IDS) main function is to aid the administrator in the detection of the type of attack that is being carried to the system. Usually, the IDS also help the administrator find and execute a solution to the problem as well as a plan of action on future detections. These systems trace and record logs, signature and triggered events. Usually, the IDS is attached to the firewall (Which I’m speaking down below) and the network router.
The most popular IDS tools I found are Snort and Cisco Network-Based IDS. Both successfully notify the user real-time, the signatures of attacks made to the network. The main advantage of Cisco IDS is the results obtained in the aftermath of the events (Reassembly of IPs and TCP sessions) and Cisco continuous support to the client. Meanwhile, Snort is open-source, cheaper to implement (Hardware wise), and flexible (Only requires Linux) and has multiple modalities where it can be implemented.
I don’t know what to say about my new habit of making very late publication of our weekly reports (And any report in general).
This week the rest of the team primary focus was to film and deliver the final project video, and myself, I worked in the design of the project poster. The one that we needed to present at “The Engineering Expo”. I’m very proud of that poster, I think it ended up real nice
I’m proud of our project. I think we worked very well and accomplished the delivery of a nicely done (And well tested) product. I’m still amazed at how bad I’m at playing it. But the doubts about myself got at ease when I saw at the expo how most of the people who played were having difficulties playing, because it is indeed, a difficult project. I guess my teammates just practiced a whole lot more when designing the levels and testing them.
See you the next time!
Miguel Montoya
Esperanto enthusiast
ʕ•ᴥ•ʔ
I leave you my poster down below.
Please, only share.
