Starting with the basics, IoT (Internet of Things) refers to the concept of tangible devices—fridges, cars, security cameras—being hooked up with wires, electronics—sensors—and software and having access to a network to communicate with one another, broadcast data to other. In IoT, these intelligent fridges are called a Thing; that is a device with an IP address and the ability to transmit data over a network.
Any device that has been hijacked is called zombie or bot; an IoT Thing that has been taken over is then called a Thingbot—honestly, I think they messed up, zombie horde sounds way cooler than Botnet. Anyway, a Botnet is a distributed network made up of many of these IoT Things, that have been hijacked—by malware—to relay messages on command.
The bot part of the Botnet connects to a control center, usually just an encrypted chat room or a bot-exclusive chat room. At any moment the owner of the botnet can access the control server and ask its members to do stuff, like dance or destroy humanity. These botnets can be used perform distributed attacks, like DDoS; to steal data; to redistribe the malware that infected them, becoming the thing they swore to destroy in the first place—I trusted you . . . you were my brother, Anakin; generate bitcoins; or simply download and run a file. An example of a Botnet malware is Mirai.
How can I protect my Thing from becoming a Zombie?
Upgrade its firmware and secure access to it with smart user-and-password combos.
This post will deal with DoS (Denial of Service) and DDoS (Distributed Denial of Service). Los Dedos te atacan comes from DDoS sounding like dedos (fingers in spanish) when reading from a spanish perspective.
DDoS and DoS attacks have the same goal. Render an online service—like an API, online gaming networks like Xbox Live or PlayStation Network, or your average webpage—unavailable for its legitimate users. This is usually done by flooding the victim’s server with requests or performing a particular request that triggers some action to bring the server down. In the end, both these attacks set their aim at the Availability part of the CIA Triad.
A traditional DoS attack consists on the same computer performing these requests, so you could imagine this type of attacks would be easy to defend against. SPOILER ALERT: they are. Usually just a check for the same IP address making multiple requests in a short span of time does the trick. The real problem lies with DDoS, mainly because of the first D.
DDoS attacks are the steroid-pumped version of DoS attacks, is just mentioned, because of the Distributed part of it. A DDoS attack is based on the same idea, but instead of a single computer, the culprit of the attack is a network of computers of any type—hijacked personal computers, remote servers from all around the globe, or IoT things, like fridges or security cameras. The fact that this network could be distributed, in the geographical sense, means that identifying the attacking computers is harder and takes much more time.
Types of DoS
Now onto the details, these are the classes of DoS attacks:
TCP.
This type of attack attempts to block all the available connections to the infrastructure by using up all their TCP ports.
Volumetrics.
Consume all of the victim’s bandwidth with gigabyte-sized requests.
Fragmentation.
Flood the victim with fragments and overwhelm their server’s reassembly capability.
Application.
Specific flaws in applications, like a backdoor of sorts.
This post will deal with the CIA, but it won’t be about the usual, let’s call it fun and secretive CIA, this is about the concept of information security called The CIA Triad, which is a model that guides and evaluates policies regarding information security inside an organization. These three letters stand for Confidentiality, Integrity, and Availability.
Spies by Emory Allen on Flickr under a CC License.
Confidentiality
Generally, this concept refers to the rules that limit access to the provided information. This concept revolves around privilege, in the sense of user privilege—not the fuzzy SJW privilege—, like an administrator user, a public user or a specific user. Confidentiality relies on the following three principles—this is quickly becoming a tree, isn’t it . . . —: Identity, Authorization and Authentication, because if any of these is compromised, so is confidentiality. Let’s say someone steals your online credentials, your identity has been hijacked, and now they can access your stuff, so this service’s confidentiality is lost. In reality, confidentiality is all about how your data is classified and how credentials are secured.
Integrity
This concept refers to making sure that information gets to where its headed with no detours and without losing anything on the journey. That is, make sure the information hasn’t been tampered with when traveling from source to destination or whenever it makes a pit stop. One way to prove integrity is to add a hash along with the message, and on the recipient’s end the hash is calculated and compared against the one included with the message; if it matches, the data received hasn’t lost its value.
Availability
To make sure that a service is available for use. A secure service should be reliably available to the right people. This concept is the target of DDoS (Distributed Denial of Service) Attacks; not only is this concept a target of man, but also of nature, hurricanes, earthquakes, floods, etc., can all affect the availability of a service. A way to fight the forces of nature is to back up, and have redundant traffic routing . . . just in case.
After the marathonic run of the first week, which was clearly the first—not the second—, we’ll continue at a more leisurely pace along with testing, as we’ll have more testable code, with developing a level loader by integrating a database and more HTTP verbs and all that web stuff.
This week I’ll be working on loading levels from a JSON so that in future weeks we can focus on storing levels as JSONs somewhere off in a database by the beach, perhaps next to an ice cream shop . . . or at least someplace where they sell Cornettos.
This week flew by fast, and so did progress of the project. This week on code, I left the basic game movements ready, movement, jumping and gravity, collisions, and the hardest, wall jumps; now all that’s left is some enemies, level design and testing the API. This can be found in our public Github repository, in which we’re using the good’l Gitflow Workflow—at least I’m trying to get the team on board with the basic feature/develop/master. I’m also attempting to get them to write out descriptive commits, with a title and description, so that in case of a metaphorical fire, we’ve got a metaphorical little fire fighter.
There’s a live demo—and here’s where we’ll be hosting the game unless we need some processing power—hosted using Heroku. Now that I’m on the topic of platforms, let’s get into frameworks, I tested p5.js with p5.play; played—hehe—around with the physics, and we decided we’d be sticking with for the long run. For testing purposes I suggested Chai, but Miguel later discovered a more complete ensemble for testing in Javascript including Chai, Mocha, Nook.
The game’s name hasn’t changed, It’s not raining, and I haven’t got an umbrella, because I don’t need it, as it’s not raining. So I guess I’m fine.
Wow wow wow it’s here. First week. We have some things to do in this space of time. Let’s get to it. On the menu, as an aperitive I’ll be looking at frameworks for browser-based game development that hopefully include sprite rendering and a bit of physics, for the main dish, a smoked unit testing module for NodeJS with garlic.
Dinner by Renis Traidas on Flickr under a CC License.
As of now, I’m thinking of the following technologies and will be trying them out—will post more about that at the end of the week.
p5.js
p5.js is a Javascript library that aims at making drawing code accessible, with a wide range of functionality in the software sketchbook variety. I’m interested in p5 because of some additional libraries its community provides, mainly p5.play which, SURPRISE SURPRISE, has 2D Sprite management and 2D Physics. I’ll be making a very simple movement demo by the end of the week with some squares.
Unit Testing in NodeJS
I don’t really have any candidate for this aspect . . . by the end of the week I aim at having one. Looking for some mock HTTP Requests and Unit testing for the p5.play library, mock some collisions for the 2D Physics, this last one I could develop from scratch with a simple assert—I think NodeJS had an Assert method.
Anyway . . .
Reading by Eugene Kim on Flickr under a CC License.
That’s what this week will be all about, catch you later.
This is the working title for our project which will be a browser-based game with online leaderboards. The game will be a platformer with a timer, obstacles (traps), enemies that aren’t that OK with you blowing past their obstacles and have taken to arms against the player’s life. The enemies (possibly of the flora variety) just want to bring rain back to their land to prosper, but the player (possibly a little flame) doesn’t care that much for rain.
Cloudy day by Fred Moore on Flickr under a CC License.
The team
My team for the development of this course’s project will be: Miguel Montoya, Gerardo Juárez, Andrés Barro, and Arturo Fornés—that’s me.
TC3045, or Calidad y Pruebas de Software (Software Quality and Testing) makes me think about how testing can lead to quality software and that with great power comes great responsibility; power being software skills, and responsibility refers to, hehe, responsibility . . . to the client and to delivering a quality product. Ken—the teacher of said course—says we’ll be focusing on a project, so I’m betting we’ll be applying TDD (Test Driven Development) to this project. We’ll also be blogging the planning process and progress of development; here I’m hoping we can provide some quality assurance and put in practice some concepts I learned in my Software Project Management courses such as risk assessment.
Fight Club by Huub Zeeman on Flickr under a CC License
Will #AbolishGrades work for this course?
I just hope we don’t end up with some team infighting and actually get something done, but anyway, that’s the struggle of every class with a project. But here in Ken’s courses working a project with the endless feedback loop that’s bound to happen with #AbolishGrades Croom style will be great for meeting requirements and delivering a quality product.
In regards to blogging, I think it fits software development as documentation and as a progress tracking tool. I personally don’t mind writing, just sometimes have to get over a mental block to start.
Anyway . . .
. . . here’s to a great semester and, for me, an Empire Strikes Back quality sequel to #AbolishGrades. Wait, it’s my third course . . . oh no, here come the Ewoks.
– Arturo Fornés, the guy from the soon to be updated About page.
This post will cover Chapter 17 & 18 & 19 of Software Project Survival Guide and Chapter 8 of The Pragmatic Programmer.
Let’s get to wrapping. To wrap up first hold a change board meeting at the end of each stage that includes the whole staff to evaluate changes that were deferred during each stage. Wrap-up is time to recalibrate estimates, see if milestones were met, whether necessary tasks were omitted, and in general if the project scope still aligns with the estimated at the start.
Evalutate performance against the project plan, whether the team performed technical reviews, kept track of progress and follow the plan. If the plan wasn’t followed, see why, if the plan resulted impossible to follow, replan.
The end by Christ Lofqvist on flickr under a CC License
To fully conclude a stage archive the environment that was used to create the software, in the future the team might need to recreate the software at a certain stage, and collect data into logs to serve as reference for future work and estimates. This is stored in Project History.
At the end of the project as a whole, gather all the data you can, e-mails, summaries, and most important, subjective opinions of team members. Hold a meeting, why not? Everybody loves meetings. In it, team members will discuss candidly their insights; a questionnare can be an alternative to this meeting.
To complete the Project History Document include both objective, quantitative information about the project and the team’s subjective, qualitative impressions. Now this document will serve as reference. For full reaping of this document in the future, conclude it in the following two ways: create a planning checklist based on the work done for the project and add the major risks to a general Top 10 Risks List template.
To fully conclude, a list of Do’s.
Create and follow a Software Development Plan.
Empower project personnel.
Minimize the bureaucracy.
Define the requirements baseline, and manage changes to it.
Replan when necessary.
Reestimate system size, effort, and schedule periodically.
Define and manage phase transitions.
Foster a team spirit.
Start the project with a small senior staff.
Now onto the Don’ts:
Don’t let team members work in an unsystematic way.
Don’t set unreasonable goals.
Don’t implement changes without assessing their impact.
Don’t let additional complexity creep in.
Don’t overstaff.
Don’t relax standards.
Onto the last Pragmatic advice. This time it’s pragmatism for the whole team. Teams should be divided based around functionality, some team will cover a certain subsystem defined in the architecture, another will serve as the change board, and so on. Automate everything that must be done systematically, people aren’t as efficient at standard procedures as one may think. Leave testing and installations to machines. Design a test case that can be performed without any human intervention, this way test can be performed more frequently.
No phase can be counted as done until it passes every test designed for it. A fun but risky way to assure a module, class or routine is fully done is to design a project saboteur, to branch out their version of the current software and introduce bugs to see if the automated testing will catch it. Regarding bugs, once a developer finds one, they should make it their mission that no one else finds that bug, put it under change control to be dealt with.
On documentation, it should be done in parallel to development. Each module should be accompanied by its respective documentation, in code and in a separate markup language document, signed by its developer in some way, be proud of your work, developer.
This post will cover Chapter 16 of Software Project Survival Guide.
The entire team must gather around a common goal: driving the software to a releasable state. By doing this, quality is ensured by focusing on polishing key factors of the code at each stage. Developers may begin to work on the next stage’s detailed design, when they’re ready to release the current stage, but must be ready to drop everything and go back to correct any defects.
Noel Gallagher by Peter Hutchins on flickr under a CC License
As to when to release, there are some techniques, the most basic one consists on defect counting if the defect count is under a certain number by the end of the stage, it is determined to be ready for release; defect density consists on averaging out the number of defects per line of code; defect pooling, for this keep two pools of defects with arbitrarily separated defects, report defects into the first and report into the second, the number of unique defects is given by the union of both pools, compare this against the approximate total number of defects given by the product of both pools divided over their intersection; defect seeding consists in planting errors in the code and having another team find them.
The development team along with the testing team should keep a public note of the defects detected and work being done on them. A public space such as the break room, an office or meeting room is usually OK, a private website could also work.
Keeping a release checklist can help review the release and on being prepared for it. It should consist on the critical release activities the team wouln’t like to forget in the heat of the moment. Similarly a release sign-off form ensures that every member of the project team is in accordance to releasing the software at each stage.
I’m now singing In the Heat of The Moment, your wonderwall guy.
