Monday, 5 October 2020

La tragedia dei click day

Il problema nel caso dei click day non é soltanto tecnico. È strategico, istituzionale e, per dirla tutta, proprio costituzionale.

La scelta di fare i click day é assolutamente sbagliata. Ma la colpa di tale scelta non ricade esclusivamente sulla Regione Siciliana. Anzi, il morbo del click day é purtroppo un morbo nazionale, che ammorba il Bel Paese da troppo tempo. È ora di liberarsene.

La "costituzione più bella del mondo" non può essere in effetti tanto bella, se permette veramente misure come i click day. Ecco, proibire sostanzialmente ed esplicitamente i provvedimenti a pioggia sarebbe una gran buona modifica alla costituzione della Repubblica Italiana.

La politica deve scegliere strategie ed implementare misure universali, non provvedimenti a pioggia.

La nostra classe politica ha dimostrato di essere capace di fare misure universali: il tanto discusso reddito di cittadinanza é nei fatti una misura universale. 

Se non ci sono i soldi per fare le misure universali, non si devono fare misure a pioggia, perché al contribuente che é chiamato a sostenerli fanno più danni dei benefici che apportano ai pochi beneficiari.

I click day, come i bandi, distorcono il mercato, favorendo immeritatamente chi vince.

Lo sviluppo economico e sociale di una comunità viene favorito dall'apertura di mercati e istituzioni, e sfavorito dalla loro chiusura. Aprire soltanto le istituzioni, senza agire sui mercati, danneggia le possibilità di sviluppo tanto quanto l'opzione di aprire soltanto i mercati senza aprire le istituzioni.

I click day, a parte l'infelice itanglese della denominazione, da un lato sembrano a prima vista una scelta di apertura delle istituzioni, perché si spera che adottandolo dovrebbe venire meno il potere di intermediazione della politica, se non peggio della burocrazia.

Astraendo dal caso specifico, apro qui una piccola parentesi tecnica: incidentalmente, in generale a me, per deformazione professionale, rimangono da sempre parecchi dubbi anche sulla trasparenza dei click day, da chiunque realizzati. Mi faccio in merito domande come: vengono pubblicati i log dei server? Viene pubblicato e sottoposto a pubblica verifica il codice sorgente della soluzione informatica? Come e da chi questa viene compilata nel programma che poi viene effettivamente utilizzato? Chi controlla e verifica chi gestisce le varie fasi del sistema?

Chiusa la parentesi tecnica, anche ipotizzando che la soluzione tecnologica adottata fosse assolutamente trasparente e funzionasse tutto alla perfezione, il problema dei click day non é tecnico.

Il problema dei click day é questi strumenti a pioggia provocano necessariamente una distorsione del mercato, inaccettabile in paesi moderni e sviluppati.

Con strumenti come i click day, si agisce, forse, nella direzione di una maggiore apertura delle istituzioni, ma in realtà purtroppo non si agisce contemporaneamente nella direzione di apertura dei mercati, proprio perché alla fine della fiera rimangono figli e figliastri.

L’alternativa ai click day, ma anche ai bandi, ed a tutti i provvedimenti a pioggia, é quella di adottare esclusivamente strumenti universali, come potrebbe essere ad esempio, ed é un mero esempio e se ne potrebbero fare molti altri, quello di abbassare a tutti le imposte in maniera progressiva. Mentre i click day distorcono il mercato, abbassando le imposte in maniera progressiva non bisognerebbe passare da nessuno, ci sarebbero regole chiare e uguali per tutti.

Thursday, 1 October 2020

Sql Server features affecting security

A number of security benchmarks (e.g. CIS v1.0.0, FedRAMP, ..) those days we are recommending to disable Microsoft Sql Server features such as remote access, contained database authentication, cross db ownership chaining, allow updates, .. unless we actually have a real requirement for those features.

The rationale is that disabling those features, we would shrink the surface attack area.

A first step we can take is to get a report of which features are actually enabled in our database systems. The following query will do the deed (per instance):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
CREATE TABLE #Database
(
[Name] VARCHAR(255),
[Feature] VARCHAR(255)
)
 
EXEC sp_MSforeachdb N'
BEGIN
	INSERT INTO	#Database
	SELECT	''?'' AS [Name], NAME AS [Feature]
	FROM	sys.configurations
	WHERE	NAME IN ( ''allow updates'', ''cross db ownership chaining'',
                 ''contained database authentication'', ''remote access'')
			AND Cast(value AS INT) = 1
END
'
SELECT * FROM #Database
DROP TABLE #Database

What if we find out that some of those features affecting security is actually enabled?
Here is a query which will reconfigure all the databases in a given instance, disabling 
remote access, one of those features:. 

1
2
3
4
5
6
7
EXEC sp_MSforeachdb N'
BEGIN
	EXEC sp_configure ''show advanced options'', 1 RECONFIGURE WITH OVERRIDE
	EXEC sp_configure ''remote access'', 0 RECONFIGURE
	EXEC sp_configure ''show advanced options'', 0 RECONFIGURE
END
'

As usual:

Caveat: generally, don't use the above or similar scripts in Production, as long as you don't understand and accept the consequences. 

Caveat: always read the message log.

Caveat: sp_MSforeachdb is undocumented, and AFAIK unsupported.

Caveat: the code above is provided "as is", without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. in no event shall the author be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the code above.