ESC

John.Bass

's profile
image
Owner/Sr Engineer

John Bass is a seasoned hardware/software developer and consultant, with over 40 years of industry experience, in a broad span of industry applications. Formal education is diverse with Business, Science, Statistics, Electrical Engineering, and Computer Science training over 11 years, resulting in a B.S. Computer Science from CalPoly, San Luis Obispo. Something like a computer engineering degree, with a strong science and business background. Extensive industry experience with drivers, porting, and operating systems, combined with hardware/software/firmware development of server level systems, embedded systems, motion control systems, and robotics. Other experience includes Reconfigurable Computing applications with Xilix FPGA's, 802.11 mesh networks, and Canopy Wireless networks.


John.Bass

's contributions
  • 05.18.2015
  • When STEM becomes STEAM
  • Hmm ... there are several comments that engineers also need to be artists ... that engineers have to wear all the hats .... like the folks expecting engineers to also be responsible for function AND style .... there is another whole non-engineer support industry that does human factors, product style, packaging, to manage appeal for brand management. And another whole field in college to train those folks. If engineers are responsible for their job too, does that mean to do engineers jobs right they need an additional 30 units in course work to do that job right too? What are the people that take that course work expected to do after engineers put them out of a job?
  • 10.22.2014
  • Should your company build or buy its IoT infrastructure?
  • Devices for the factory floor are likely to be significantly more secure if home grown. I'm pretty sure a factory shutdown from IoT devices being purposefully bricked after a targeted economic warfare attack is a lot more expensive than just having your plant engineers or engineering team grow the devices at home. $40 devices sourced from Asia or the Middle east, have very high risks of being trojan horses. Especially if attached to the internet.
  • 04.30.2015
  • First three rules of IoT security
  • Certainly :) The first question is how much is necessary, and how much should be a necessary part of the deployment environment. $100 bills are designed for very cost effective utility ... they are designed with enough security to minimize counterfeiting, but all the physical access security preventing theft, denial-of-service, storage security, and other security concerns is required for it's ownership are to be built into the owners security models. A $5 IoT fire sensor, or heat sensor, doesn't need $100/unit of amortized NRE to secure and test every possible network attack vector, including those that might cause unintended operation. Nor does a $5 bill. If it's near free, sure include it, as long as it doesn't create a long term product liability for other reasons.
  • 05.18.2015
  • When STEM becomes STEAM
  • I mentored/coached a FIRST/VEX team for about 8 years, which had an awesome impact giving a few dozen kids grounding in engineering, and leading a few of them to complete engineering degrees ... including my daughter graduating as an MechEng last year. The majority of the kids had been left behind by the mainstream programs in the school where were art, music, and sports centric. The school still has a dying industrial "arts" program, barely still functioning ... mostly around a wood shop program. Little to no support from the school admin, with it's school to work skills message nearly lost these days on a system that depreciates technical training to jobs at the high school level.
  • 04.30.2015
  • First three rules of IoT security
  • In general a well secured organization probably has as many firewalls and independently controlled secure areas of access, as it would have for the same information/resources in the physical domain. Firewall at internet gateway, is rather equivalent to the guard station at the front gate to the campus, rejecting individuals who have no sponsored access to the corporate facility grounds. Multiple firewalled subnets, are rather equivalent to the physical domain of a guest entrance, employee entrance, shipping/receiving entrance, construction entrance ... etc .... each with it's own guard, badge requirement, and locked/restricted domains. High security firewalled subnets with strong access controls, are rather equivalent to high physical security areas of a company ... the various secure locked vaults/cages/rooms that hold sensitive records, high value inventory, and extremely high risk production areas which do not allow ANYONE without the required vetted access cards. If your company campus has significant multiple layered physical access controls, it's rather thoughtless for IT staff to protect the campus with a single gateway firewall to the internet.
  • 04.30.2015
  • First three rules of IoT security
  • @RichQ .... So your IT staff goes home at 6:30PM, and the state sponsored hackers on the other side of of the globe are just getting into work .... they have a clear 12 hours to probe, attack, and brick IoT devices running your factory floor .... which nominally produces about $100,000 of product per hour. Or they just emptied all your proprietary data files from your file server. It makes EVERY rational bit of sense to keep EVERY possible attack away from every valuable resource to avoid economic losses. I'm pretty sure when the factory floor is bricked, you boss is going to ask why it wasn't firewalled from the janitors computer that opened the door to the factory floor. .... or to the file servers.
  • 12.05.2014
  • 7 steps to security for the Internet of Things
  • The first step is to deny the IoT device access to the open internet, and place it behind a hard firewall from the internet ... and preferably behind a hard firewall to the rest of your network. And then enable VPN access through the firewalls, for well vetted devices that actually need access to the device. It doesn't matter how well the developers implement security ... if attack vectors exist in the chosen system and libraries. It's safe to assume there are unknown attack vectors and that they WILL be exploited if exposed to the open network, or to compromised machines inside your own network. Limit the damage by network design ... firewall your business, firewall your data center, firewall your factory floor, firewall your office machines, and by all means firewall your pools of IoT devices that might be trojan horses back into your network.
  • 04.30.2015
  • First three rules of IoT security
  • Jonny .... strongly agree ... the developer can design and implement security into their code, and even verify it well, with strong security oriented design reviews ... only to get caught with unknown attack vectors in the system and library code. Security starts by assuming there are, and always will be, available exploits, and deploying this gear behind a well designed firewall, with vpn access through the firewall as needed. Unwise to directly expose to public internet.
  • 04.30.2015
  • First three rules of IoT security
  • The shear complexity of SDN controllers, and many exposed services, will leave them high value targets, with regular compromises for a number of years. Maybe longer if the code base doesn't mature quickly, and changes continue to be frequently introduced for years. Leaving multiple vectors for attack for a long while. The OpenDaylight Netdump hack is probably just the first of many. Bugtraq is useful for both sides of the security game. SSL is far from perfect, even after a couple decades.